picoZ80
Übersicht
Der picoZ80 setzt das tranZPUter-Konzept fort und ersetzt eine physische Z80-CPU in einem Host- oder Industrierechner durch eine
schnellere CPU, mehr Speicher, virtuelle Geräte, Netzwerkanbindung (WiFi, BT), schnelles Laden von Anwendungen von der SD-Karte und WiFi-Verwaltung.
Es handelt sich um eine speziell entwickelte Platine, die direkt in den Z80-DIP-40-CPU-Sockel eines beliebigen älteren Z80-basierten Computers eingesetzt werden kann. Anstelle eines diskreten Z80-Prozessors beherbergt die Platine einen RP2350B-Mikrocontroller — ein Dual-Core-150MHz-Cortex-M33-Baustein, der mit bis zu 300MHz betrieben werden kann — dessen programmierbare I/O-(PIO)-Zustandsautomaten die vollständige, zyklusgenaue Kontrolle über die Z80-Adress-, Daten- und Steuerbusse übernehmen.
Der picoZ80 ist kein einfacher Emulator-Adapter. Jede Bustransaktion wird in Echtzeit von den PIO-Engines des RP2350 verarbeitet, wodurch das Hostsystem exakt dasselbe Bus-Timing erhält, das es von einem echten Z80 erwarten würde. Gleichzeitig ermöglichen der zweite Kern des RP2350 und der großzügige On-Chip-SRAM, kombiniert mit 8MB externem PSRAM und 16MB Flash, eine nahezu unbegrenzte Palette an Fähigkeiten, die auf die rohe Z80-Schnittstelle aufgesetzt werden können — darunter beschleunigte Ausführung, virtualisierter Speicher, ROM-Banking, virtuelle Laufwerke und vollständige Maschinenpersönlichkeits-Emulation.
Ein ESP32-Co-Prozessor stellt WiFi- und Bluetooth-Konnektivität, SD-Karten-Massenspeicher und eine browserbasierte Verwaltungsoberfläche bereit. Die gesamte Konfiguration wird über eine einzige, menschenlesbare
config.json-Datei auf der SD-Karte gesteuert, sodass keine Neukompilierung erforderlich ist, um die Speicherbelegung, ROM-Images oder Treiberauswahl der Platine zu ändern.
Der picoZ80 wurde in mehreren Sharp-MZ-Rechnern erfolgreich betrieben. Für diese Maschinen — und perspektivisch auch für andere Z80-Systeme — werden Personas entwickelt, die dringend benötigte Funktionen bereitstellen, wie gebanktes RAM/ROM, Floppy-Disk-Emulation, QuickDisk-Emulation, ROM Filing System, TranZPUter Filing System, die alle gleichzeitig funktionsfähig sein können.
Die Konfiguration ist vollständig JSON-gesteuert; die Unterstützung eines neuen Z80-basierten Hosts erfordert lediglich die Bearbeitung einer Konfigurationsdatei und, wo neues I/O-Verhalten benötigt wird, das Hinzufügen eines kleinen C-Treibers
zur Codebasis.
- Drop-in Z80-CPU-Ersatz
- wird in jeden Z80-DIP-40-Sockel eingesetzt. Der Host sieht durchgehend normales Z80-Bus-Timing. - Zyklusgenaue PIO-Busschnittstelle
- drei RP2350-PIO-Zustandsautomaten verarbeiten Adress-, Daten- und Steuersignale gleichzeitig mit voller Z80-Busgeschwindigkeit. - Großer Speicherraum
- 8MB PSRAM, organisiert als 64 Bänke × 64KB, ergeben insgesamt 4MB gebankten Adressraum pro CPU-Kontext. - ROM/RAM-Banking
- Speicherblöcke sind in 512-Byte-Granularität konfigurierbar und können als ROM, RAM, physischer Host-Speicher oder virtuelle Funktionshandler zugeordnet werden. - Framework für virtuelle Geräte
- jeder 512-Byte-Block des Speichers oder I/O-Portbereich kann durch eine C-Funktion hinterlegt werden, was vollständig virtualisierte Peripherie ermöglicht. - Maschinenpersönlichkeiten
- die Z80-Firmware kann über eine JSON-Konfiguration für den Betrieb in jedem Z80-Host konfiguriert werden. Personas sind für mehrere Sharp-MZ-Maschinen verfügbar (MZ-80K, MZ-700, MZ-800, MZ-80A, MZ-80B, MZ-2000, MZ-2200, MZ-2500, MZ-1500), den Amstrad PCW-9512 und den Tatung Einstein TC-01 sowie eine OpenZ80-Vanilla-Persona für Experimentierer, die den picoZ80 in eine selbst entworfene Platine oder eine Maschine ohne dedizierten Treiber einbauen. Gezielte Build-Varianten (BaseZ80, SharpZ80, AmstradZ80, TatungZ80, OpenZ80) ermöglichen maschinenspezifische Firmware für reduzierte Binärgröße. - Floppy- und QuickDisk-Emulation
- WD1773-kompatibler Floppy-Disk-Controller und Sharp QuickDisk-Laufwerksemulation unter Verwendung von DSK/RAW/D88-Images auf der SD-Karte. - WiFi und Web-Verwaltung
- der integrierte ESP32 bietet eine siebenseitige Bootstrap-Web-Oberfläche für Konfiguration, Dateiverwaltung, OTA-Firmware-Updates und Persona-Auswahl. - ICE-Debug-Shell
- ein ICE-Debugger mit 49 Befehlen, zugänglich über USB CDC Serial, bietet Breakpoints (8 gleichzeitig), Einzelschrittausführung, Ausführungs-Trace, Z80-Registerinspektion, Speicher- und I/O-Lesen/Schreiben, einen integrierten Z80-Disassembler und -Assembler, Disk-Imaging, Bus-Diagnose und Systemstatusüberwachung. - Duale Firmware-Partitionen
- zwei unabhängige 5MB-Firmware-Slots ermöglichen sichere OTA-Upgrades; die aktive Partition wird über die Web-Oberfläche oder den Bootloader ausgewählt. - USB-Firmware-Update
- der Bootloader stellt eine USB-Brücke für Firmware-Flashing bereit, ohne dass ein Hardware-Debugger benötigt wird.
Hardware
Die picoZ80-Platine (Revision 2.5) ist eine kompakte, mehrlagige Platine, die so konstruiert wurde, dass sie in den physischen Formfaktor des Z80-DIP-40-Gehäuses und den verfügbaren Platz in typischen Retro-Computer-Gehäusen passt. Die gesamte Logik arbeitet mit 3,3V; Pegelwandlung und Treiberstrom-Aspekte für den 5V-Host-Bus werden im Schaltungsdesign berücksichtigt.
Die Platine integriert fünf Subsysteme auf einer einzigen Leiterplatte: den RP2350B-Prozessor, die Z80-Busschnittstelle, den ESP32-Co-Prozessor, die Stromversorgung und einen USB-Hub.
Hauptkomponenten
- RP2350B (Cortex-M33 Dual-Core)
- Hauptprozessor, getaktet mit bis zu 300MHz. Führt die Z80-Emulations-Hot-Loop auf Core 1 aus und verarbeitet Datei-I/O, USB und ESP32-Relay auf Core 0. 512KB On-Chip-SRAM. Die RP2350B-Variante (im Gegensatz zum RP2350A) bietet 48 GPIO-Pins, die für den vollständigen Z80-Bus benötigt werden. - 16MB SPI Flash
- speichert den Bootloader, zwei Anwendungs-Firmware-Slots, zwei Konfigurations-Slots und eine allgemeine Konfigurationspartition. Das gesamte adressierbare Layout erstreckt sich von 0x10000000 bis 0x11000000. - 8MB PSRAM (SPI)
- externer Pseudo-Static-RAM mit 64 Bänken × 64KB gebankiem Adressraum für die emulierte CPU. Über eine dedizierte SPI-Peripherie mit dem RP2350 verbunden. - ESP32-Co-Prozessor
- bietet WiFi (802.11 b/g/n, AP- und Client-Modi), Bluetooth, SD-Kartenleser und Webserver. Kommuniziert mit dem RP2350 über ein binäres IPC-Protokoll via 50MHz FSPI (mit CRC32-Integritätsprüfung, vorab zugewiesenen DMA-Kanälen und Burst-Sektor-Transfers von bis zu 16 Sektoren pro Transaktion) sowie eine UART-Verbindung mit 460,8kbaud für Steuerbefehle. - SD-Karten-Slot
- FAT32, verwaltet vom ESP32. Speichertconfig.json, ROM-Images, Disk-Images (DSK, QuickDisk, RAM-Disk) und TZFS/RFS-Dateisystembäume. - USB-Hub
- integrierter USB-Hub für Host-Konnektivität und Firmware-Update-Bridging. - 3,3V-Stromversorgung
- effizienter Buck-Converter, der von den 5V am VCC-Pin des Z80-Sockels gespeist wird.
Die picoZ80-Hardware wurde in KiCad entworfen. Die aktuelle Revision ist v2.5. Schaltplan- und PCB-Layout-Dateien sind im Projekt-Repository unter
Blatt 1 — RP2350B-Prozessor
kicad/PICOZ80/ verfügbar.
Der Schaltplan ist in fünf Blätter unterteilt:
Alle RP2350B-GPIO-Zuweisungen, Entkopplung, 12MHz-Quarzoszillator, 16MB Flash und 8MB PSRAM-Verbindungen. Das RP2350B-QFN-80-Gehäuse wurde speziell wegen seiner 48-GPIO-Anzahl gewählt — der vollständige Z80-Bus (16 Adress- + 8 Daten- + 12 Steuersignale) plus ESP32 SPI/UART- und USB-Signale belegen praktisch jeden verfügbaren Pin.

ESP32-S3-PICO-1-Modul, SD-Karten-Schnittstelle (SPI), Chipantenne, Debug-Header und Interprozessorkommunikationsleitungen (FSPI-Bus mit 50MHz, UART mit 460,8kbaud). Die SD-Karten-Signale und Interprozessor-SPI/UART sind in diesem Blatt klar getrennt.

Die 40-poligen DIP-Sockel-Verbindungen und das Busschnittstellen-Widerstandsnetzwerk. Adressleitungen A0–A15, Datenleitungen D0–D7 und alle Z80-Steuersignale (MREQ, IORQ, RD, WR, M1, RFSH, BUSREQ, BUSACK, HALT, INT, NMI, WAIT, CLK, RESET) werden über Reihenwiderstände zu dedizierten RP2350-GPIO-Pins geführt, die von den PIO-Zustandsautomaten überwacht werden.

TLV62590BV synchroner 5V-auf-3,3V-Buck-Converter mit Eingangs-/Ausgangsfilter-Kondensatoren. Der Converter muss die kombinierte Last des RP2350B bei bis zu 300MHz, 8MB PSRAM, ESP32 und USB-Hub vom einzelnen 5V-VCC-Pin des Z80-DIP-40-Sockels versorgen.

CH334F USB-Hub-Controller mit Mini-B-Anschluss, 12MHz-Quarz und Downstream-Ports, die sowohl zum RP2350 (für Firmware-Update-Bridging) als auch zum ESP32 (für direkten USB-Zugriff bei neueren Platinenrevisionen) geführt werden.

Die Leiterplatte wurde so klein wie möglich gestaltet, um alle notwendige Schaltungstechnik unterzubringen und in die Grenzen eines DIP-40-Sockels zu passen.
Es wurden die kleinsten Bauteile verwendet, die noch manuell bestückt werden konnten, d.h. 0402/0603-Passivkomponenten und 0,5mm-IC-Pin-Abstand, um die Gesamtgröße zu reduzieren, und ein 6-Lagen-Stackup wurde gewählt, um alle erforderlichen Komponenten unterzubringen.
Die ersten Designs, v2.0 und v2.1, wurden manuell bestückt mit punktueller Lötpastenauftragung, manueller Bauteilplatzierung und einer Heißluft-Rework-Station. Version 2.2 wurde manuell mit einer Schablone und einem Reflow-Ofen bestückt. v2.3a und v2.5 wurden bei einem PCB-Fertiger bestückt.
PCB-Übersicht
Klicken Sie hier, um ein interaktives PCB-Bauteilplatzierungsdiagramm und die Stückliste anzuzeigen.
Architektur
Dual-Core-Design
Die beiden Cortex-M33-Kerne des RP2350B haben vollständig getrennte Aufgabenbereiche und kommunizieren über eine Intercore-Nachrichtenwarteschlange (
PIO-Busschnittstelle
queue_t).
Core 0 verarbeitet alle nicht-echtzeitkritischen Aufgaben: USB-Bridge und CDC-Serial, Firmware-Update-Koordination, Datei-I/O (weitergeleitet an den ESP32 über UART), ESP32-Befehlsweiterleitung (Floppy/QuickDisk-Image-Wechsel, Konfigurations-Neuladungen, Versionsabfragen), Partitionsverwaltung und Watchdog-Überwachung. Ein Hardware-Watchdog-Timer überwacht die Boot-Sequenz und die Hauptschleife, wobei der Boot-Fortschritt über RP2350-Scratch-Register verfolgt wird, die Watchdog-Resets überleben. Umfassende Fault-Handler erfassen Registerzustand und Diagnoseinformationen im PSRAM und ermöglichen eine Post-Reset-Analyse von Hard Faults, Bus Faults und Usage Faults. Ein persistentes PSRAM-Log (plogf) erfasst boot-kritische Meldungen, bevor USB verfügbar ist, und ergänzt das Standard-debugf-Debug-Ausgabesystem.
Core 1 führt ausschließlich die CPU-Emulations-Hot-Loop aus. Er bedient die PIO-FIFOs zur Verarbeitung von Z80-Bustransaktionen, löst jede Adresse gegen die Speicherbelegung auf und leitet die Transaktion entweder an die physische Host-Hardware weiter (PHYSICAL-Typ), bedient sie aus dem PSRAM (RAM/ROM-Typen) oder ruft eine Handler-Funktion für virtuelle Geräte auf (FUNC-Typ). Die Latenz auf diesem Pfad wird minimiert, indem die innere Schleife im SRAM gehalten wird und die 512KB RP2350-SRAM als schnelle Nachschlagetabelle für Speicherblock-Zeiger verwendet werden.
Die Z80-Busschnittstelle ist vollständig in RP2350-PIO-Assembler implementiert (
z80.pio). Der RP2350 bietet drei PIO-Blöcke (PIO 0, PIO 1, PIO 2), jeweils mit vier Zustandsautomaten. Die Z80-Firmware nutzt alle drei PIO-Blöcke:
- PIO 0 — Adress- und Datenbus (GPIO 0–23)
- verarbeitet den 16-Bit-Adressbus (A0–A15, GPIO 0–15) und den bidirektionalen 8-Bit-Datenbus (D0–D7, GPIO 16–23). Die Zustandsautomaten führen die Programmez80_addrundz80_datagleichzeitig aus, übertragen Adresswörter und steuern oder samplen Datenbytes synchron. - PIO 1 — Steuersignale, Zyklusausführung und DRAM-Refresh (GPIO 16–47)
- führt die Hauptbus-Steuerprogramme gegen den oberen GPIO-Bereich aus: der Zyklus-Zustandsautomat (z80_cycle) orchestriert alle Z80-Buszyklen einschließlich integrierter DRAM-Refresh-Erzeugung, Bus Request/Acknowledge (z80_busrq), NMI-Erkennung (z80_nmi), Taktsynchronisation (z80_clk_sync) und Interrupt-Acknowledge-Behandlung (z80_int_ack). - PIO 2 — Host-Timing, Reset und Wait States
- verwaltet die zeitkritischen Interaktionen zwischen dem RP2350 und dem Host-Z80-Bus, die auch dann korrekt bleiben müssen, wenn Core 1 internen Speicher bedient. Vier dedizierte Zustandsautomaten laufen in PIO 2:- RESET-Erkennung (
z80_reset) — überwacht die Host-RESET-Leitung und signalisiert Core 1, damit der Emulationszustand bei jedem Hardware-Reset sauber reinitialisiert werden kann. - Wait-State-Generator (
z80_wait) — fügt konfigurierbare T-Zyklus-Wait-States ein (gesteuert durch den JSON-Parametertcycwait), indem /WAIT auf dem Host-Bus aktiviert wird, wodurch einzelne Buszyklen gestreckt werden, um die Timing-Anforderungen langsamerer Peripherie oder gebanktem ROM/RAM zu erfüllen. - T1-Synchronisation (
z80_sync) — erkennt die steigende Flanke von T1 bei jedem Buszyklus (den Zeitpunkt, an dem der Z80 eine gültige Adresse auf den Bus legt) und signalisiert Core 1 über IRQ. Diese Synchronisation ist wesentlich für Anwendungen, die auf den Host-Takt für präzises Timing angewiesen sind — einschließlich Software-Warteschleifen und zeitkritischer I/O wie Kassettenmotor-Steuerung und seriellem Bit-Banging — und stellt sicher, dass interne RP2350-Speicheroperationen keinen wahrnehmbaren Timing-Drift verursachen.
- RESET-Erkennung (
z80.pio, gruppiert nach PIO-Block:
| PIO | Programm | Funktion |
|---|---|---|
| 0 | z80_addr |
Gibt die 16-Bit-Adresse (A0–A15) auf den Bus aus und signalisiert den Zyklusstart. |
| 0 | z80_data |
Treibt oder sampelt D0–D7, mit Tri-State-Steuerung während BUSRQ. |
| 0 | z80_cycle |
Buszyklus-Sequenzer auf oberster Ebene — orchestriert Fetch-, Lese-, Schreib-, I/O- und DRAM-Refresh-Zyklen. |
| 0 | z80_fetch |
Opcode-Fetch-Buszyklus (M1 + MREQ + RD). |
| 1 | z80_mem_read |
Speicher-Lese-Buszyklus (MREQ + RD). |
| 1 | z80_mem_write |
Speicher-Schreib-Buszyklus (MREQ + WR). |
| 1 | z80_io_read |
I/O-Lese-Buszyklus (IORQ + RD). |
| 1 | z80_io_write |
I/O-Schreib-Buszyklus (IORQ + WR). |
| 1 | z80_busrq |
Verwaltet BUSREQ/BUSACK und gibt /IORQ, /MREQ, /RFSH, /M1, /HALT, /WR, /RD frei. |
| 1 | z80_nmi |
Erkennt die NMI-Aktivierung und signalisiert Core 1. |
| 1 | z80_clk_sync |
Synchronisiert die PIO-Zustandsautomaten mit dem Z80-CLK-Signal. |
| 1 | z80_int_ack |
Behandelt Interrupt-Acknowledge-Zyklen (M1 + IORQ). |
| 2 | z80_reset |
Überwacht die Host-RESET-Leitung und signalisiert Core 1, den Emulationszustand zu reinitialisieren. |
| 2 | z80_wait |
Fügt konfigurierbare T-Zyklus-Wait-States auf dem Host-Bus ein (gesteuert durch tcycwait). |
| 2 | z80_sync |
Erkennt T1 bei jedem Buszyklus und signalisiert Core 1 über IRQ, wodurch interne Speicheroperationen mit dem Host-Takt synchronisiert werden. |
Die Zustandsautomaten kommunizieren über PIO-IRQ-Flags anstelle von Polling, was die Latenz zwischen den Automaten eliminiert: IRQ 0 signalisiert Adress-/Zyklusstart, IRQ 1 signalisiert die Datenphase, IRQ 2 zeigt die T1-Erkennung an, IRQ 3 signalisiert ein RESET-Ereignis, IRQ 4 signalisiert NMI und IRQ 6 signalisiert eine aktive BUSRQ.
Da PIO-Programme unabhängig von den Cortex-M33-Kernen ausgeführt werden, reagiert die Busschnittstelle auch dann deterministisch, wenn Core 1 mit PSRAM-Zugriffen oder Aufrufen virtueller Geräte beschäftigt ist.
Dreistufiges Speichermodell
Speicherzugriffe werden über drei Stufen mit steigender Latenz aufgelöst:
Stufe 1 — RP2350 SRAM (512KB, null Wait States)
Ein 128-Einträge-Array von 32-Bit
Der PSRAM hält 64 Bänke mit 64KB RAM- oder ROM-Images, plus ein 64KB
Firmware, ROM-Images und die minifizierte
Ein 128-Einträge-Array von 32-Bit
membankPtr-Werten, eines pro 512-Byte-Block des vollen 64KB Z80-Adressraums, gibt Core 1 ein O(1)-Blocktyp-Lookup für jede Bustransaktion. Dieses Array ist die innere Dispatch-Tabelle: jeder Eintrag kodiert den Blocktyp und, für PSRAM-hinterlegte Blöcke, den PSRAM-Offset.
Stufe 2 — Externer PSRAM (8MB, SPI)Der PSRAM hält 64 Bänke mit 64KB RAM- oder ROM-Images, plus ein 64KB
memPtr-Zeiger-Array, ein 64KB memioPtr-Funktionszeiger-Array und ein 64KB ioPtr-I/O-Funktionszeiger-Array. Die PSRAM-Zugriffslatenz ist deterministisch und wird über die SPI-Peripherie des RP2350 mit DMA verarbeitet.
Stufe 3 — 16MB SPI FlashFirmware, ROM-Images und die minifizierte
config.json werden im Flash gespeichert. ROM-Images werden beim Booten vom Flash in den PSRAM kopiert und zur Laufzeit dann aus dem PSRAM bedient. Der Flash wird während normaler Z80-Bustransaktionen nicht angesprochen.
Speicherblöcke werden in 512-Byte-Granularität konfiguriert. Die verfügbaren Blocktypen sind:
| Typ | Beschreibung |
|---|---|
PHYSICAL |
Durchleitung zur echten Host-Hardware — der RP2350 gibt den Bus frei und lässt den physischen Host-Speicher antworten. |
PHYSICAL_VRAM |
Wie PHYSICAL, jedoch mit zusätzlichen Wait States für Host-Video-RAM-Timing. |
PHYSICAL_HW |
Durchleitung für Host-Hardware-Register. |
RAM |
Lesen/Schreiben — hinterlegt durch PSRAM-Bank. |
ROM |
Nur Lesen — hinterlegt durch PSRAM-Bank; Schreibzyklen werden stillschweigend ignoriert. |
VRAM |
PSRAM-hinterlegtes Video-RAM; Schreibzyklen werden zusätzlich zum physischen Host-VRAM gespiegelt. |
FUNC |
Virtuelles Gerät — jeder Zugriff löst einen C-Funktionsaufruf aus, der beliebige I/O-Emulation ermöglicht. |
PTR |
Byte-weise Umleitung — jedes Byte des 512-Byte-Blocks kann auf jeden anderen Block oder Typ verweisen. |
Der 16MB Flash ist wie folgt partitioniert:
| Partition | Adressbereich | Größe | Inhalt |
|---|---|---|---|
| Bootloader | 0x10000000–0x1001FFFF |
128KB | USB-Bridge, Firmware-Update, Partitions-Auswahl |
| App Slot 1 | 0x10020000–0x1051FFFF |
5MB | Haupt-Z80-Firmware (Partition 1) |
| App Slot 2 | 0x10520000–0x10A1FFFF |
5MB | Haupt-Z80-Firmware (Partition 2) |
| App Config 1 | 0x10A20000–0x10C9FFFF |
2,5MB | ROM-Images + minifizierte config JSON (Slot 1) |
| App Config 2 | 0x10CA0000–0x10F1FFFF |
2,5MB | ROM-Images + minifizierte config JSON (Slot 2) |
| General Config | 0x10F20000–0x10FFEFFF |
892KB | Kerneinstellungen, Scratch-Bereich |
| Partition Table | 0x10FFF000–0x11000000 |
4KB | Aktiver Slot, Prüfsummen, Metadaten |
Jeder Konfigurations-Slot kann bis zu 64 ROM-Images und eine 64KB minifizierte JSON-Konfiguration aufnehmen. Der aktive Slot wird in der Partitionstabelle gespeichert und kann über die Web-Oberfläche oder durch Halten der entsprechenden Taste beim Booten umgeschaltet werden.
Maschinenpersönlichkeiten
Die aktive Persona wird über die Personality-Seite der Web-Oberfläche oder durch Bearbeiten der
Peripherie- und Dateisystem-Treiber
config.json ausgewählt.
Die Firmware unterstützt ein gezieltes Build-System, das maschinenspezifische Binärdateien erzeugt:
Netzwerk-Dateiserver (netfs.py)
pZ80-BaseZ80 enthält alle Treiber (Sharp + Amstrad + Tatung), pZ80-SharpZ80 enthält nur Sharp-MZ-Treiber, pZ80-AmstradZ80 enthält nur Amstrad-PCW-Treiber, pZ80-TatungZ80 enthält nur Tatung-Einstein-Treiber, und pZ80-OpenZ80 ist die Vanilla-/Experimentier-Persona, die nur die maschinenunabhängigen Schnittstellenkarten bereitstellt (siehe OpenZ80 — Experimentier-Persona weiter unten). Jedes Ziel wird durch Kompilierzeit-Definitionen gesteuert (INCLUDE_SHARP_DRIVERS, INCLUDE_AMSTRAD_DRIVERS, INCLUDE_TATUNG_DRIVERS, INCLUDE_OPEN_DRIVERS). Die folgenden Peripherietreiber sind verfügbar:
Sharp MZ-Serie
Bei der Kompilierung mit INCLUDE_SHARP_DRIVERS werden die folgenden Sharp-Peripherietreiber eingebunden und können über die JSON-Konfiguration an jede virtuelle Hardware-Persona gebunden werden:
- MZ700.c — Sharp MZ-700-Peripheriesatz
- verarbeitet das charakteristische Bank-Switching, Video und Tastatur-I/O des MZ-700 auf Peripherieebene. - MZ80K.c — Sharp MZ-80K-Peripheriesatz
- Emulation des ursprünglichen MZ-80K von Sharp aus dem Jahr 1978, modelliert nach dem MZ-80A-Treiber. Stellt das SP-1002 Monitor-ROM (0x0000–0x0FFF), 2KB VRAM (0xD000–0xD7FF), das 8255 PPI, den 8253 PIT und den LS367-Tastaturscanner (0xE000–0xE7FF) sowie die native MZ-80FD/MZ-80FIO-Floppy-Boot-ROM-Region (0xF000–0xF3FF) bereit. Implementiert den MEMSW/MEMSWR-Speichertausch (verlagert das SP-1002-Monitor zwischen 0x0000 und 0xC000), sodass CP/M ausgeführt werden kann. Unterstützt sowohl physischen (Drop-in-Ersatz in einem echten MZ-80K) als auch virtuellen (PSRAM-basierten) Betrieb; CP/M erfordert den virtuellen Modus (oder den treiberinternen Speicher-Remap-Pfad), da der ursprüngliche MZ-80K keine Speichertausch-Hardware besitzt. Der MZ-80K kann zusätzlich zu seinem eigenen nativen Floppy-Controller den gesamten Satz der MZ-80A-Schnittstellenkarten binden. Zwei unterschiedliche Floppy-Pfade werden unterstützt: (1) die native MZ80FIO-Schnittstelle (Toshiba T3444M-Controller) — die ursprüngliche MZ-80FD-Disk-Schnittstelle —, die alle MZ-80K-Disks bootet und liest, einschließlich Spiele, Anwendungen, BASIC und CP/M; und (2) die MZ80AFI-Karte (der WD-basierte FDC des MZ-80A), die von CP/M verwendet wird — sie kann MZ-80K-CP/M booten und ursprüngliche MZ-80K-CP/M-Disks aus CP/M heraus lesen (eingebunden als Laufwerke C:/D:). Verwenden Sie MZ80FIO für die allgemeine MZ-80K-Disk-Nutzung und MZ80AFI beim Betrieb von CP/M. Sub-Interfaces: RFS, MZ80FIO (nativer T3444M-Floppy), MZ80AFI, MZ-1E14, MZ-1E19, MZ-1R12, MZ-1R18, MZ-1R37, PIO-3034. - MZ80A.c — Sharp MZ-80A-Peripheriesatz
- vollständige MZ-80A-Maschinenemulation einschließlich SA-1510 Monitor-ROM, 2KB VRAM, Intel 8253 PIT (Programmable Interval Timer mit allen sechs Zählermodi), Intel 8255 PPI (Programmable Peripheral Interface), LS367-Tastaturscanner und dem MEMSW/MEMSWR-Speichertausch-Mechanismus für CP/M-Unterstützung (tauscht Monitor-ROM bei 0x0000 mit RAM bei 0xC000). Unterstützt sowohl physischen (echte Hardware) als auch virtuellen (PSRAM-basierten) Betrieb, einschließlich Mischbetrieb, bei dem der Treiber virtuell läuft, aber ein physischer Floppy-Controller verwendet wird. Sub-Interfaces: RFS, MZ80AFI, MZ-1E14, MZ-1E19, MZ-1R12, MZ-1R18. - MZ2000.c — Sharp MZ-2000-Peripheriesatz
- vollständige MZ-2000-Maschinenemulation mit Boot/Normal-Speichermodus-Umschaltung (BST/NST), Zeichen- und Grafik-VRAM-Overlay mit Bankauswahl, Intel 8253 PIT (4 MHz), Intel 8255 PPI (Kassetten- und Speichermodus-Steuerung), Z80 PIO (Tastatur und VRAM-Paging) und MB8866 FDC. Unterstützt sowohl physischen Modus (Drop-in Z80-Ersatz in einem echten MZ-2000 mit automatischer Boot/Normal-Modus-Erkennung) als auch virtuellen Modus (vollständige PSRAM-basierte Emulation mit IPL-ROM-Spiegelung). Sub-Interfaces: RFS, MZ80AFI, MZ-1E14, MZ-1E19, MZ-1R12, MZ-1R18. - MZ2200.c — Sharp MZ-2200-Peripheriesatz
- MZ-2200-Maschinenemulation basierend auf der MZ-2000-Architektur mit 8253 PIT, 8255 PPI, Z80 PIO, MB8866 FDC und Farb-CRT. Unterstützt BST/NST-Speichermodus-Umschaltung mit VRAM-Overlay. Sub-Interfaces: RFS, MZ-8BFI/E0054PA, MZ-1E14, MZ-1E19, MZ-1R12, MZ-1R18. - MZ80B.c — Sharp MZ-80B-Peripheriesatz
- MZ-80B-Maschinenemulation mit 2K IPL-ROM, BST/NST-Modusumschaltung, Monochrom-Display mit dualen Grafik-VRAM-Seiten, 8253 PIT (31,25 kHz), 8255 PPI, Z80 PIO und Grafikseiten-Auswahl. Alle 10 Erweiterungskarten-Schnittstellen werden unterstützt. Sub-Interfaces: MZ-8BFI/E0054PA, MZ-1E14, MZ-1E19, MZ-1R12, MZ-1R18, MZ-1R23, MZ-1R37, PIO-3034, Celestite, MZ-1E30. - MZ2500.c — Sharp MZ-2500 (SuperMZ)-Peripheriesatz
- MZ-2500-Maschinenemulation mit 8-Seiten-MMU (64 Speicherblöcke), Kompatibilitätsmodi (MZ-2000, MZ-80B, nativ), OPN YM2203 FM+PSG-Sound, G-CRTC-Grafikcontroller, MB8876 FDC, 16-Einträge-Grafikpalette, Interrupt-Controller, RTC, Joystick-Ports. Der virtuelle Modus unterstützt Interrupt-gesteuerte Software über benutzerdefinierte fetchByte- und RETI-Handler, die physische M1-Buszyklen ausführen (benötigt für die M1-getakteten internen Uhren des Gate Arrays), D88-natives Diskformat mit Sparse/Contiguous-Auto-Erkennung und einmalige Interrupt-Unterdrückung während der Initialisierung. Sub-Interfaces: MZ-8BFI/E0054PA, MZ-1E14, MZ-1E19, MZ-1R12, MZ-1R18, MZ-1R23, MZ-1R37, PIO-3034, Celestite, MZ-1E30. - MZ1500.c — Sharp MZ-1500-Peripheriesatz
- MZ-700-Obermenge mit eingebautem Quick Disk-Laufwerk, Programmable Character Generator (PCG), Stereo-PSG-Sound (SN76489AN), Z80 PIO-Drucker-Schnittstelle, 8253 PIT und DIP-Schalter MZ-700/MZ-1500-Modusauswahl. Sub-Interfaces: RFS, MZ-1E05, MZ-1E14, MZ-1E19, MZ-1R12, MZ-1R18, MZ-1R23, MZ-1R37, PIO-3034, Celestite. - MZ800.c — Sharp MZ-800-Peripheriesatz
- Dual-Modus-Treiber, der im MZ-700-Kompatibilitätsmodus oder im nativen MZ-800-Modus läuft und zur Laufzeit über das Display-Mode-Register des GDG (Graphics Display Generator, Port 0xCE) umschaltet. Der native Modus ergänzt 320×200- / 640×200-Grafik mit einer 4- oder 16-Farben-Palette (VRAM-Ebenen bei 0x8000–0xBFFF), SN76489-PSG-Sound (Port 0xF2), Memory-Banking-Ports 0xE0–0xE6, WD1773-FDC und QuickDisk; der MZ-700-Modus stellt das speichergemappte 8255/8253 und Text-VRAM zum Ausführen von MZ-700-Software und CP/M bereit. Virtueller Modus; spielt ein physisches RETI auf dem realen Bus ab, damit die Z80-PIO-Interrupt-Daisy-Chain (IM2) weiterhin aus dem PSRAM funktioniert. Sub-Interfaces: RFS, MZ80FIO, MZ80AFI, MZ-1E05, MZ-1E14, MZ-1E19, MZ-1E30, MZ-1R12, MZ-1R18, MZ-1R23, MZ-1R37, MZ-8BFI, PIO-3034, Celestite, MZ-8BIO3, MZ-1E24. - WD1773.c — Floppy-Disk-Controller
- emuliert einen WD1773-FDC mit Unterstützung für 80-Spur-, 2-Kopf-, 8-Sektoren-pro-Spur-Disk-Images in DSK-, RAW- und D88-Formaten, gespeichert auf der SD-Karte. WD1773-Register werden als FUNC-Typ-I/O-Blöcke abgebildet. - T3444M.c — Toshiba T3444M/T3444A Floppy-Disk-Controller (MZ-80K)
- emuliert den Toshiba T3444M/T3444A FDC, der von der MZ-80FD-Floppy-Einheit des Sharp MZ-80K verwendet wird. Liest CPC-Extended-DSK-Images mit der nativen Geometrie des MZ-80K (35 Spuren, 2 Köpfe, 16 Sektoren/Spur, 128-Byte-FM-Sektoren), mit bis zu vier gleichzeitigen Laufwerks-Images. Ein dedizierter DSK-Parser durchläuft dieTrack-Info-Signaturen auf der Disk, da die CPC-DSK-Spurgrößentabelle des MZ-80K unzuverlässig ist. Wird von der MZ80FIO-Schnittstelle verwendet — als ursprünglicher/nativer Controller des MZ-80K bootet und liest er jeden Typ von MZ-80K-Disk, nicht nur CP/M. - MZ80FIO.c — MZ-80FD / MZ-80FIO Floppy-Disk-Interface (MZ-80K)
- emuliert die Sharp MZ-80FD/MZ-80FIO-Schnittstelle — die ursprüngliche MZ-80K-Disk-Schnittstelle — unter Verwendung des Toshiba T3444M-Controllers. Stellt das FDIF-Boot-ROM bei 0xF000–0xF3FF sowie die T3444M-Register- und Befehlsports bei 0xF8–0xFB bereit. Bootet und liest alle MZ-80K-Disks (Spiele, Anwendungen, BASIC und CP/M), unterstützt bis zu vier Laufwerke und Disk-Wechsel zur Laufzeit über die Web-Oberfläche. Für den Betrieb von CP/M kann stattdessen der MZ80AFI-Controller des MZ-80A verwendet werden — es ist immer nur eine Floppy-Schnittstelle gleichzeitig aktiv, und wenn beide konfiguriert sind, hat MZ80FIO Vorrang. - QDDrive.c — QuickDisk-Laufwerk
- emuliert das Sharp QuickDisk-Laufwerk mit sequenziellem Zugriff unter Verwendung von QD-Image-Dateien auf der SD-Karte. Der Treiber bietet vollständige Z80 SIO/2-Emulation (Kanal A für Spiralspur-Daten, Kanal B für Motor-/Statussteuerung), komplett mit Hunt-Phasen-Sync-Byte-Erkennung, Motorsteuerung über RTS und asynchronen Intercore-Dateioperationen für SD-Karten-Zugriff. - RFS.c — ROM Filing System
- implementiert das RFS-Banking und die Dateischnittstelle, die das Laden von MZF-Programmdateien von der SD-Karte ermöglicht. Die RFS-Persona enthält CP/M v2.23 (48K), den benutzerdefinierten SA-1510 BASIC-Interpreter und Microsoft BASIC v4.7, alle erweitert mit SD-Karten-Lese-/Schreibzugriff, sodass Programme und Daten direkt von der SD-Karte geladen und gespeichert werden können, ohne Kassetten- oder Floppy-Hardware. - TZFS.c — TranZPUter Filing System
- ein funktionsfähiger Multi-Bank-Low-Level-Monitor und ein Dateisystem, modelliert nach dem TZFS der tranZPUter SW und ihrem virtuellen K64F-I/O-Prozessor, und als auswählbare Schnittstelle auf der MZ-700-Persona angeboten (registriert neben RFS inMZ700.cund in der Praxis mit ihm gegenseitig ausschließend). Er erweitert den ursprünglichen MONITOR 1Z-013A um SD-Karten-Zugriff, ROM-Banking, einen Assembler/Disassembler und Werkzeuge, und er bootet CP/M unter dem Monitor. Die Speichermodi der Maschine werden durch Schreiben von tranZPUter-Modi (TZMM_ORIG/BOOT/TZFS/TZFS2/TZFS3/TZFS4/CPM/CPM2/COMPAT) an den I/O-Port0x60umgeschaltet, was die Bank-Zeiger neu ausrichtet; der Z80 fordert Dateisystem- und CP/M-Dienste mitOUT (0x68)an, was eine Dienstanforderung an Core 0 einreiht (Verzeichnisauflistung, Datei-Laden und die CP/M-Laufwerksdienste). Da der picoZ80 keinen direkten SD-Zugriff hat, werden CP/M-512-Byte-Sektoren über den ESP32 gegen ganze Image-Dateien gelesen und geschrieben, wobei die Image-Pfade pro Laufwerk aus den JSON-Einträgenparam[].fileder Schnittstelle stammen (Fallback-VorlageCPM/SDC16M/RAW/CPMDSK<nn>.RAW). Das TZFS-ROM istroms/tzfs.binauf der SD-Karte, assembliert ausTZFS/asm/tzfs.asmdes begleitenden TZFS-Projekts. Es wird inconfig_MZ-700_MZ-700.jsonmit"enable": 0ausgeliefert — vorhanden, aber standardmäßig deaktiviert — und wird in der JSON oder über die Konfigurationsseite der Web-GUI aktiviert. - MZ-1E05.c — Floppy-Disk-Interface-Einheit
- emuliert die Sharp MZ-1E05-Floppy-Disk-Controller-Einheit, die auf dem WD1773 FDC basiert. - MZ8BFI.c — MZ-8BFI / E0054PA Floppy-Disk-Interface (MZ-2000)
- emuliert das Floppy-Disk-Interface des MZ-2000 unter Verwendung des MB8866/WD1773-kompatiblen FDC. Im Gegensatz zum MZ-1E05 hat das MZ-8BFI kein integriertes Treiber-ROM — der FDC-Code befindet sich im MZ-2000 IPL-ROM. Unterstützt D88-Disk-Image-Format. 40 Zylinder, 2 Köpfe, 16 Sektoren/Spur, 256-Byte-Sektoren. - MZ-1E14.c — QuickDisk-Controller mit BIOS-ROM (MZ-700 / MZ-800)
- emuliert den MZ-1E14 QuickDisk-Controller, der ein integriertes BIOS-ROM für die MZ-700- und MZ-800-Maschinen enthält. - MZ-1E19.c — QuickDisk-Controller ohne BIOS-ROM (MZ-800 / MZ-2000 / MZ-2200 / MZ-2500)
- emuliert den MZ-1E19 QuickDisk-Controller, der kein integriertes BIOS-ROM hat und für die MZ-800-, MZ-2000-, MZ-2200- und MZ-2500-Maschinen vorgesehen ist. - MZ-1R12.c — 32KB batteriepufferte RAM-Karte
- emuliert die Sharp MZ-1R12 32KB batteriepufferte RAM-Erweiterung. Anstatt eine echte Batterie zu verwenden, wird das RAM-Image auf der SD-Karte persistiert und von dort wiederhergestellt. Die Karte wird häufig verwendet, um eine Anwendung zu speichern, damit sie beim Booten sofort verfügbar ist und lange Kassetten-Ladezeiten vermieden werden. - MZ-1R18.c — 64KB RAM-Karte
- emuliert die Sharp MZ-1R18 64KB RAM-Erweiterung, die typischerweise als RAMFILE-Disk zur Programmspeicherung oder zur Bereitstellung von zusätzlichem Speicher für benutzerdefinierte Anwendungen verwendet wird, die mehr als den Standard-Adressraum benötigen. - MZ-1R23.c — MZ-1R23 Kanji-ROM / MZ-1R24 Dictionary-ROM
- emuliert die 128KB Kanji-ROM- (16×16 JIS-Muster) und optionalen 256KB Dictionary-ROM-Karten. ROM-Dateien werden von der SD-Karte geladen. I/O-Ports B8h–B9h mit Auto-Increment-Lesung. - MZ-1R37.c — MZ-1R37 640KB EMM (Expanded Memory Manager)
- emuliert eine 640KB Expanded-Memory-Karte mit 20-Bit-Adressraum und I/O-Port-Adressen-Latching. - PIO-3034.c — IO DATA PIO-3034 320KB EMM
- emuliert eine 320KB Expanded-Memory-Karte mit 19-Bit-Adresszähler und Auto-Increment-Datenport. - Celestite.c — Celestite LAN / Speicher-Kompositkarte
- emuliert einen Wiznet W5100-Ethernet-Controller (Registerdatei), Interrupt-Controller, UFM-persistenten Speicher, integriertes MZ-1R12 32KB CMOS-RAM (erweiterbar auf 64KB) und optionalen MZ-1R37 640KB EMM. I/O-Ports 60h–6Fh. Die netfs.py Dateiserver-Adresse ist über den JSON-Parameteripkonfigurierbar (z.B."192.168.1.210:6800"). Die Phase-2-Implementierung bietet echte TCP/IP-Netzwerkanbindung über die ESP32-Brücke — W5100-Socket-Befehle (OPEN, CONNECT, LISTEN, SEND, RECV, CLOSE) werden an den ESP32 weitergeleitet, der tatsächliche BSD-Socket-Operationen durchführt und so der Celestite-Karte die Kommunikation mit Netzwerkdiensten wie dem netfs.py-Dateiserver ermöglicht. - SASI.c + MZ1E30.c — MZ-1E30 SASI-Festplatten-Interface
- emuliert den Sharp MZ-1E30 SASI-Festplatten-Controller für MZ-2500/MZ-80B. Unterstützt bis zu 4 Disk-Targets (~21,4 MB je, 256-Byte-Blöcke), 32KB IPL-ROM und bedarfsgesteuertes Sektor-I/O von SD-Karten-Disk-Images. SASI-Befehle: TEST_UNIT_READY, REQUEST_SENSE, READ(6), WRITE(6), SEEK(6), INQUIRY. I/O-Ports 0xA4–0xA5 (SASI-Bus), 0xA8–0xA9 (ROM-Zugriff). - MZ8BIO3.c / MZ1E24.c — RS-232C-Serielle-Schnittstellenkarten
- Zweikanal-Serienkarten, aufgebaut auf einem emulierten Zilog Z80 SIO. Ports 0xB0–0xB3 (konfigurierbare Basis): Kanal A bei 0xB0/0xB1, Kanal B bei 0xB2/0xB3. Kanal A ist auf USB-CDC-Serienport 2 und Kanal B auf USB-CDC-Serienport 3 gebrückt, sodass ein Terminal-, Modem- oder Dateiübertragungsprogramm auf dem Host-PC mit Sharp-Serien-Software kommuniziert. Der MZ-8BIO3 verwendet die "BI"-Steckverbinderverdrahtung, der MZ-1E24 die Sharp-"ST"-Verdrahtung; ansonsten identisch. Kein ROM. Verfügbar auf den MZ-700-, MZ-800-, MZ-80B- und MZ-1500-Personas. - Z80SIO.c — Zilog Z80 SIO/2-Emulation
- registergenauer Z80 SIO (WR0–WR7, RR0–RR2, Z80-Mode-2-vektorisierte Interrupts mit einer 4-stufigen In-Service-Daisy-Chain), verwendet von den MZ-8BIO3- und MZ-1E24-Karten. Nutzt sperrfreie Single-Producer/Single-Consumer-Ringpuffer, um Bytes zwischen der Z80-Emulation (Core 1) und dem USB-CDC-Dienst (Core 0) zu übertragen.
INCLUDE_AMSTRAD_DRIVERS werden die folgenden Amstrad-Peripherietreiber eingebunden:
- PCW9512.c + uPD765.c — Amstrad PCW-9512-Peripheriesatz
- vollständige Amstrad PCW-9512-Emulation mit Gate Array (ASIC), NEC uPD765 FDC (CPC DSK-Format), 512KB RAM mit 4-Bank-16KB-Paging, 8041-Typenrad-Druckercontroller, Bootstrap-Sequenz-Emulation und physischem Disk-Imaging. Virtueller und physischer Modus werden unterstützt.
INCLUDE_TATUNG_DRIVERS werden die folgenden Tatung-Peripherietreiber eingebunden:
- EinsteinTC01.c + EinsteinFDC.c + WD1770.c — Tatung Einstein TC-01-Peripheriesatz
- vollständige Tatung Einstein TC-01-Emulation mit Z80A @ 4MHz, 64KB RAM + 8KB umschaltbares ROM (X-TAL MOS), ROM/RAM-Umschaltung über Port 0x24 (jeder Zugriff schaltet um; Schreibvorgänge gehen immer in den RAM), WD1770 FDC mit virtueller Disk-Unterstützung (40 Spuren, 1 Kopf, 10 Sektoren, 512 Bytes — 200KB-Disks), TMS9129 VDP (Video Display Processor) mit Inter-Access-Timing-Erzwingung (~2us Abstand), AY-3-8910 PSG (3-Kanal-Sound) an Ports 0x02-0x03, Z80 CTC (4 Kanäle) an Ports 0x28-0x2B, Z80 PIO an Ports 0x30-0x33, Tastaturschnittstelle an Port 0x20 und physisches Disk-Imaging (physische Floppy in DSK lesen, DSK auf physische Floppy schreiben). Virtueller und physischer Modus werden unterstützt. Sub-Interface: EinsteinFDC (2 Laufwerke, DSK/D88-Format-Unterstützung).
INCLUDE_OPEN_DRIVERS (dem OpenZ80-Ziel) stellt die Firmware eine bewusst „vanilla" gehaltene Z80-Persona (src/drivers/Other/Open.c) bereit, die keine maschinenspezifische Hardware mitbringt. Ihr entscheidender Wert liegt darin, dass Sie virtuelle Schnittstellenkarten, die von anderen Sharp-, Amstrad- und Tatung-Maschinen entlehnt sind, auf einem maßgeschneiderten oder anderweitig nicht unterstützten Z80-Computer hinzufügen können — sodass Sie neue Software für diese Karten schreiben oder bestehende Software für den Betrieb auf Ihrer eigenen Maschine anpassen können. Sie ist für zwei Arten von Experimentierern gedacht:
- Sie entwerfen Ihre eigene Z80-Platine — setzen Sie den picoZ80 in den 40-poligen Sockel ein und lassen Sie ihn als einfachen Z80 arbeiten. Im physischen Modus werden der vollständige 64K-Adress- und I/O-Raum direkt an Ihre Platine durchgeleitet, und jede aktivierte maschinenunabhängige Schnittstellenkarte wird an ihren I/O-Ports überlagert. Im virtuellen Modus präsentiert OpenZ80 ein flaches 64K-RAM, in das Sie ein oder mehrere eigene ROM-Images sequenziell ab 0x0000 laden können, sodass Sie eine Platine in Betrieb nehmen können, die über keinen eigenen Speicher oder ROM verfügt.
- Sie besitzen einen Z80-Computer, für den es keinen dedizierten picoZ80-Treiber gibt — beginnen Sie mit OpenZ80 und einem der vorhandenen Maschinentreiber als Basis und passen Sie ihn dann für Ihre Maschine an (siehe unten).
build_tzpuPico.sh open.
Aufbauen auf einem vorhandenen Treiber oder BIOS
Um den picoZ80 an eine neue Maschine anzupassen, nehmen Sie einen der mitgelieferten Treiber als Ausgangspunkt und passen ihn an. Die Persona-Treiber liegen unter src/drivers/ — Sharp-Maschinen in src/drivers/Sharp/ (z.B. MZ700.c, MZ80A.c, MZ80K.c, MZ2000.c), der Amstrad PCW in src/drivers/Amstrad/PCW9512.c, der Tatung Einstein in src/drivers/Tatung/EinsteinTC01.c und die Vanilla-Persona in src/drivers/Other/Open.c. Wählen Sie die Maschine, die Ihrer am nächsten kommt, und bearbeiten Sie deren Speicherbelegung, I/O-Handler und ROM-Layout.
Die passenden Monitor-, IPL-, CP/M-BIOS- und Floppy-Boot-ROMs werden als kommentierter Z80-Assembler-Quellcode in den Begleitprojekten RFS und TZFS, in deren asm/-Verzeichnissen, bereitgestellt, sodass Sie sie für Ihre Maschine neu bauen oder patchen können:
- Monitor-ROMs —
RFS/asm/sp1002.asm(MZ-80K SP-1002),RFS/asm/sa1510.asm(MZ-80A SA-1510),RFS/asm/1z-013a.asmundTZFS/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. - CP/M-BIOS —
RFS/asm/cbios.asmundRFS/asm/cpm22-bios.asm(auchTZFS/asm/cbios.asm/cbiosII.asm). - Floppy- / QuickDisk-Boot-ROMs —
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. - Dateisystem-ROMs — das RFS-ROM selbst (
RFS/asm/rfs.asm, gebankt) und das TZFS-ROM (TZFS/asm/tzfs.asm, gebankt) können als Basis für ein eigenes In-ROM-Dateisystem verwendet werden.
Das picoZ80-Projekt enthält einen Python-basierten Netzwerk-Dateiserver (
tools/NetFileServer/netfs.py), der auf einem Windows- oder Linux-PC läuft und MZF-Programmdateien an das Sharp MZ BASIC NETx:-Gerät über das Netzwerk bereitstellt. Wenn der picoZ80 mit einer Celestite-Karte (oder einem virtuellen Celestite-Treiber) ausgestattet ist, können BASIC-Programme auf dem MZ Dateien vom Dateisystem des PCs laden, speichern und auflisten, indem sie Standard-BASIC-Befehle mit dem NETx:-Gerätepräfix verwenden.
python3 netfs.py [--port 6800] [--dir ./mzf_files] [--dir2 path] ... [--dir7 path]Der Server unterstützt die Einheiten 1–7 (
NET1: bis NET7:), die jeweils einem separaten Verzeichnis auf dem PC zugeordnet sind. Unterstützte Befehle: DIR (Verzeichnisliste), READ (Dateidaten laden), WRITE (Datei speichern), INFO (Datei-Metadaten), DELETE und CLOSE. Der Server ist multithreaded, verarbeitet MZF-Header-Parsing und -Erzeugung und enthält ein 30-Sekunden-Verbindungs-Timeout für Absturzwiederherstellung.
Build-Anleitung
Der einfachste Weg, die picoZ80-Firmware zu bauen, besteht darin, das automatisierte Setup-Skript für Ihre Plattform herunterzuladen und auszuführen. Es installiert alle Abhängigkeiten, klont die Repositories, konfiguriert die Pfade und erstellt gebrauchsfertige Build-Skripte — keine manuelle Konfiguration erforderlich.
Automatisiertes Setup — Linux / macOS
Laden Sie das Setup-Skript herunter und führen Sie es aus einem beliebigen Verzeichnis aus. Es fragt Sie nach einem Installationsort (Standard:
~/pico).
curl -O https://git.eaw.app/eaw/pico/raw/branch/master/setup_picoZ80.sh chmod +x setup_picoZ80.sh ./setup_picoZ80.sh
Das Skript führt Folgendes aus:
- Erkennt Ihr Betriebssystem (Debian/Ubuntu, Fedora/RHEL, Arch/Manjaro, macOS) und installiert die benötigten Pakete — CMake, ARM-Cross-Compiler, Git, Python, Perl, rsync.
- Klont das picoZ80-Repository, das Pico SDK (develop-Branch), Pico Examples und Pico Extras mit allen Submodulen.
- Konfiguriert die Build-Skripte mit den korrekten Pfaden und installiert das picoZ80-Board-Header in das SDK.
- Richtet optional Docker ein und lädt das Image
espressif/idf:release-v5.4für ESP32-Firmware-Builds herunter. - Erstellt
~/picoZ80_env.sh— eine Umgebungsdatei, die in zukünftigen Sitzungen eingelesen werden kann. Sie setzt alle erforderlichen Pfade und stellt die Hilfsfunktionidf54für transparente ESP32-Builds über Docker (bevorzugt) oder eine native ESP-IDF-Installation (Fallback) bereit.
# Add to your ~/.bashrc or ~/.zshrc for automatic loading: source ~/picoZ80_env.sh # Build all RP2350 targets build_tzpuPico.sh # Build a specific target family build_tzpuPico.sh sharp # Sharp MZ targets only build_tzpuPico.sh amstrad # Amstrad PCW targets only build_tzpuPico.sh tatung # Tatung Einstein targets only build_tzpuPico.sh open # OpenZ80 experimenter persona only # Build with debug symbols build_tzpuPico.sh DEBUG # Build everything including ESP32 firmware build_tzpuPico.sh ALL # Build ESP32 firmware only build_esp32Automatisiertes Setup — Windows 10 / 11
Laden Sie setup_picoZ80_windows.ps1 herunter und führen Sie es aus einer Administrator-PowerShell-Eingabeaufforderung aus:
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass .\setup_picoZ80_windows.ps1
Das Windows-Skript führt dieselben Schritte aus, angepasst an das Windows-Ökosystem:
- Installiert die benötigten Werkzeuge über
winget— Git, CMake, Ninja, Python, Perl und die ARM GNU Toolchain. Stellt manuelle Download-URLs für alle Werkzeuge bereit, die nicht automatisch installiert werden können. - Klont alle Repositories und konfiguriert die Pfade.
- Erstellt
build_tzpuPico.batundpicoZ80_env.bat, vorkonfiguriert für Ihren Installationsort. - Bietet drei Optionen für ESP32-Builds: Docker Desktop, den Espressif-ESP-IDF-Offline-Installer (~1,5 GB) oder Überspringen.
picoZ80_env.bat build_tzpuPico.bat REM build all RP2350 targets build_tzpuPico.bat sharp REM build Sharp targets only build_tzpuPico.bat ALL REM build RP2350 + ESP32 build_tzpuPico.bat esp32 REM build ESP32 firmware only
Hinweis: Führen Sie
Gezieltes Build-System
build_tzpuPico.bat nicht aus einer ESP-IDF-PowerShell/CMD-Eingabeaufforderung aus — die ESP-IDF-Toolchain überschreibt cmake und kann die RP2350-Host-Tools nicht bauen. Die Batch-Datei erkennt dies und beendet sich mit einer klaren Fehlermeldung. Die ESP-IDF-Aktivierung wird automatisch vom ESP32-Build-Schritt übernommen.
Das Build-System erzeugt maschinenspezifische Firmware-Binärdateien, um die Firmware-Größe zu reduzieren, wenn nur eine Teilmenge der Treiber benötigt wird:
| Ziel | Binär-Präfix | Enthaltene Treiber | Kompilierzeit-Definitionen |
|---|---|---|---|
BaseZ80 |
pZ80-BaseZ80 |
Alle Treiber (Sharp + Amstrad + Tatung) — universelle Binärdatei | INCLUDE_SHARP_DRIVERS, INCLUDE_AMSTRAD_DRIVERS, INCLUDE_TATUNG_DRIVERS |
SharpZ80 |
pZ80-SharpZ80 |
Nur Sharp MZ-Treiber — kleinere Firmware | INCLUDE_SHARP_DRIVERS |
AmstradZ80 |
pZ80-AmstradZ80 |
Nur Amstrad PCW-Treiber — kleinere Firmware | INCLUDE_AMSTRAD_DRIVERS, TARGET_MODEL_AMSTRAD |
TatungZ80 |
pZ80-TatungZ80 |
Nur Tatung Einstein-Treiber — kleinere Firmware | INCLUDE_TATUNG_DRIVERS, TARGET_MODEL_TATUNG |
Jedes Zielmodell hat sein eigenes Verzeichnis unter
Manuelles Setup (Referenz)
src/model/ mit einer dedizierten CMakeLists.txt, einem Einstiegspunkt und Linker-Skripten. Verwenden Sie das BaseZ80-Ziel für maximale Kompatibilität oder wählen Sie ein maschinenspezifisches Ziel für eine kleinere Binärdatei, die bequemer in die 5MB-Firmware-Partition passt.
Das Verzeichnis fw/uf2/ enthält die Bootloader-UF2-Images (für das anfängliche USB-Massenspeicher-Flashing); das Verzeichnis fw/bin/ enthält die Binär-Images (.bin) der Anwendungspartitionen für OTA-Updates. Anwendungspartitionen liegen an nicht-standardmäßigen Flash-Adressen, die das UF2-Format nicht ausdrücken kann, daher wird für alle OTA-Transfers reines Binärformat verwendet. Jedes Ziel wird in einer Standard- und einer DBGSH-Variante gebaut — die DBGSH-Variante aktiviert die vollständige ICE-Debug-Shell auf USB CDC Kanal 1.
Wenn Sie die Umgebung lieber manuell konfigurieren möchten, anstatt die automatisierten Setup-Skripte zu verwenden, sind die Schritte:
- Installieren Sie die Voraussetzungen: CMake 3.20+,
arm-none-eabi-gcc(ARM-Cross-Compiler), Git, Python 3, Perl und optional Docker oder eine native ESP-IDF-v5.4-Installation für ESP32-Builds. - Klonen Sie das Haupt-Repository:
git clone https://git.eaw.app/eaw/pico.git <root> - Klonen Sie das Pico SDK:
git clone https://github.com/raspberrypi/pico-sdk.git --branch developund führen Sie daringit submodule update --initaus. - Klonen Sie Pico Extras:
git clone https://github.com/raspberrypi/pico-extras.gitund führen Sie daringit submodule update --initaus. - Bearbeiten Sie die
PICO_PATH-Variable am Anfang vonbuild_tzpuPico.sh, sodass sie auf Ihr Stammverzeichnis zeigt. - Führen Sie
./build_tzpuPico.shaus, um die RP2350-Firmware zu bauen, oder./build_tzpuPico.sh ALL, um die ESP32-Firmware einzuschließen.
Firmware laden
Erstmaliges RP2350-Flashing
Auf der picoZ80-Platine gibt es keinen physischen BOOTSEL- oder Reset-Taster. Beide Signale sind über den 6-poligen Debug-Header zugänglich:
| Pin 1 | Pin 2 | Pin 3 | Pin 4 | Pin 5 | Pin 6 |
|---|---|---|---|---|---|
| SWCLK | SWD | Reset RP2350 | Reset ESP32 | GND | BOOTSEL |
Um den RP2350 in den Bootloader-Massenspeicher-Modus zu versetzen, verwenden Sie einen Jumper oder eine Sonde am Debug-Header:
Erstmaliges ESP32-Flashing
- Halten Sie Pin 6 (BOOTSEL) auf Low.
- Schalten Sie die Stromversorgung ein, oder setzen Sie Pin 3 (Reset RP2350) auf Low und lassen Sie ihn dann los — der RP2350 beginnt zu booten.
- Lassen Sie BOOTSEL nach dem Einschalten oder Reset umgehend los. Wenn BOOTSEL über den initialen Bootmoment hinaus auf Low gehalten wird, verhindert dies den Zugriff des RP2350 auf den FlashRAM.
- Verbinden Sie den USB-Port des picoZ80 mit einem PC — der RP2350 meldet sich als USB-Massenspeichergerät an.
- Kopieren Sie
Bootloader_<version>.uf2auf das gemountete Laufwerk. Der RP2350 flasht den Bootloader selbstständig und startet neu.
Der ESP32 wird mit
esptool über eine Python Virtual Environment geflasht. Bei neueren Platinenrevisionen erscheint der ESP32 als eigenes USB-Gerät; bei den ursprünglichen Platinen mit einem einzigen USB-Port war er nur über den RP2350 als USB-UART-Brücke erreichbar. In beiden Fällen wird Pin 4 (Reset ESP32) am Debug-Header verwendet, um den ESP32 bei Bedarf während der RP2350-Boot-Sequenz im Reset zu halten.
Richten Sie die esptool-Umgebung einmalig ein:
python3 -m venv ./venv/
source ./venv/bin/activate
cd $HOME/esptool
Flashen Sie dann alle vier ESP32-Firmware-Komponenten in einem Befehl, wobei Sie
PORT an den von Ihrem Betriebssystem zugewiesenen Geräteknoten und BINPATH an das Verzeichnis mit den kompilierten Binärdateien anpassen:
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
Alle nachfolgenden ESP32-Firmware-Updates können über die OTA-Webseite (
OTA-Updates (nach dem erstmaligen Flashing)
ota-esp32.htm) durchgeführt werden, ohne esptool zu benötigen.
Hinweis zur Platinenrevision: Die ursprünglichen picoZ80-Platinen (v2.0 bis v2.2) haben einen einzigen USB-Port, der mit dem RP2350 verbunden ist. Bei diesen Platinen muss der ESP32 über den RP2350 als USB-UART-Brücke programmiert werden. Neuere Platinenrevisionen fügen einen zweiten USB-Port hinzu, der direkt mit dem ESP32 verbunden ist, sodass esptool ihn unabhängig ansprechen kann.
- RP2350 OTA
- navigieren Sie zuhttp://<device-ip>/ota-rp2350.htm, wählen Sie die versionierte.bin-Datei ausfw/bin/und laden Sie sie hoch. Die Anwendungspartitionen liegen an nicht-standardmäßigen Flash-Adressen, daher wird reines Binärformat (nicht UF2) benötigt. Der Bootloader überprüft die Image-Prüfsumme, bevor die neue Partition aktiviert wird. - ESP32 OTA
- navigieren Sie zuhttp://<device-ip>/ota-esp32.htmund laden Sie die ESP32-Firmware-Binärdatei hoch. Der ESP32 startet automatisch in die neue Firmware. Dieselbe Seite akzeptiert auch ein versioniertes FilePack-Archiv, das das ESP32-Web-Dateisystem auf der SD-Karte aktualisiert — siehe FilePack-Upload weiter unten.
Formatieren Sie die SD-Karte als FAT32. Legen Sie
config.json im Stammverzeichnis ab. Erstellen Sie Unterverzeichnisse für ROM-Images, Disk-Images und Dateisystembäume, wie sie in Ihrer Konfiguration referenziert werden. Sobald die Platine läuft, kann die SD-Karte auch vollständig über die Web-Dateiverwaltungsseite verwaltet werden.
Debugging
Der picoZ80 unterstützt vollständiges Source-Level-Debugging beider RP2350-Kerne und des ESP32-Co-Prozessors. Der RP2350 wird über SWD mit einer CMSIS-DAP-Sonde debuggt, wobei OpenOCD einen Zwei-Ziel-GDB-Server bereitstellt (ein Port pro Kern). Der ESP32-S3 wird über seine integrierte USB-JTAG-Schnittstelle mit dem Xtensa-Toolchain-GDB debuggt.
RP2350 — SWD-Debugging
Hardwareverbindung
Verbinden Sie eine ARM DAPLink / CMSIS-DAP-Sonde (z.B. Raspberry Pi Debug Probe, Black Magic Probe oder jeden CMSIS-DAP-kompatiblen Adapter) mit dem 6-poligen Debug-Header auf der picoZ80-Platine. Es werden nur drei Verbindungen benötigt:
OpenOCD starten
OpenOCD stellt zwei GDB-Server-Ports bereit — Port
Verbinden Sie eine ARM DAPLink / CMSIS-DAP-Sonde (z.B. Raspberry Pi Debug Probe, Black Magic Probe oder jeden CMSIS-DAP-kompatiblen Adapter) mit dem 6-poligen Debug-Header auf der picoZ80-Platine. Es werden nur drei Verbindungen benötigt:
| Debug-Header-Pin | Signal | SWD-Funktion |
|---|---|---|
| Pin 1 | SWCLK | Serial Wire Clock |
| Pin 2 | SWDIO | Serial Wire Data |
| Pin 5 | GND | Massebezug |
OpenOCD stellt zwei GDB-Server-Ports bereit — Port
3333 für Core 0 und Port 3334 für Core 1. Der picoZ80 erfordert eine kleine Änderung am Standard-OpenOCD-RP2350-Zielskript, um echtes SMP-Debugging mit separaten GDB-Ports pro Kern zu ermöglichen. Kopieren Sie das Standardskript und entkommentieren Sie die target smp-Zeile:
sudo cp /usr/local/share/openocd/scripts/target/rp2350.cfg \
/usr/local/share/openocd/scripts/target/rp2350_tzpu.cfg
Bearbeiten Sie dann
rp2350_tzpu.cfg — finden Sie die target smp-Zeile innerhalb des if {[string compare $_USE_CORE SMP] == 0}-Blocks und entfernen Sie das führende #:
# Before (rp2350.cfg):
#target smp $_TARGETNAME_0 $_TARGETNAME_1
# After (rp2350_tzpu.cfg):
target smp $_TARGETNAME_0 $_TARGETNAME_1
Diese einzige Änderung aktiviert den SMP-Modus, sodass OpenOCD Core 0 auf GDB-Port 3333 und Core 1 auf Port 3334 registriert und jeder Kern unabhängig angehängt und schrittweise ausgeführt werden kann. Starten Sie OpenOCD aus dem Projektstammverzeichnis, bevor Sie GDB starten:
openocd -f interface/cmsis-dap.cfg -f target/rp2350_tzpu.cfg -c "adapter speed 5000"
Globale GDB-Initialisierung (
GDB erfordert eine explizite Erlaubnis zum automatischen Laden von verzeichnisspezifischen
~/.gdbinit)GDB erfordert eine explizite Erlaubnis zum automatischen Laden von verzeichnisspezifischen
.gdbinit-Dateien. Fügen Sie Folgendes zu ~/.gdbinit hinzu und passen Sie die Pfade an Ihren Projektstandort an (hier relativ zum Projektstamm dargestellt — verwenden Sie absolute Pfade in ~/.gdbinit, wenn Sie GDB aus verschiedenen Verzeichnissen starten):
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/.gdbinitBootloader-Debugging
Kopieren Sie die entsprechende pro-Kern-
.gdbinit-Datei in das Bootloader-Build-Verzeichnis und starten Sie dann gdb-multiarch. Die Datei .gdbinit.bootloader.3333 verbindet sich mit Core 0 (Port 3333) und protokolliert in gdb_core0.txt; .gdbinit.bootloader.3334 verbindet sich mit Core 1 (Port 3334) und protokolliert in gdb_core1.txt. Öffnen Sie zwei Terminals, um beide Kerne gleichzeitig zu debuggen:
# 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.elfHaupt-Firmware-Debugging
Die
.gdbinit-Dateien der Hauptfirmware (.gdbinit.3333 und .gdbinit.3334) definieren einen benutzerdefinierten xac <address> <count>-Befehl, der Speicher als kombinierte Hex- und ASCII-Ausgabe darstellt, sich mit dem jeweiligen GDB-Port verbinden und die Ausführung fortsetzen. Dies ist nützlich, um PSRAM-Bank-Inhalte und Speicher-gemappte Gerätezustände zu inspizieren, ohne die Emulationsschleife anzuhalten:
# 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 64ESP32 — USB-Debugging
Der ESP32-S3-Co-Prozessor hat eine integrierte USB-JTAG-Schnittstelle — es wird keine externe Debug-Sonde benötigt. Verbinden Sie ein USB-Kabel von einem Host-PC direkt mit dem ESP32-USB-Port auf der picoZ80-Platine.
Starten Sie OpenOCD mit der ESP32-S3-Built-in-JTAG-Konfiguration:
openocd -f board/esp32s3-builtin.cfg
Starten Sie dann den Xtensa-GDB mit dem ESP32-Firmware-ELF (zu finden unter
esp32/build/main.elf relativ zum Projektstamm) und verbinden Sie sich mit dem OpenOCD-GDB-Server:
xtensa-esp32s3-elf-gdb esp32/build/main.elf (gdb) target extended-remote :3333
Stellen Sie sicher, dass das ELF aus derselben Quellrevision erstellt wurde wie die auf dem Gerät geflashte Firmware, damit Symbole und Adressen korrekt übereinstimmen.
Konfiguration (JSON)
Das gesamte Verhalten des picoZ80 wird durch
config.json auf der SD-Karte gesteuert. Der RP2350 liest diese Datei beim Booten über den ESP32, minifiziert sie und speichert das Ergebnis im Flash. Wenn keine SD-Karte vorhanden ist, wird die zuvor gespeicherte Konfiguration verwendet. Die Konfiguration kann direkt im Browser über die Config-Editor-Seite bearbeitet werden.
Die Grundstruktur ist:
{
"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": [ ... ]
}
]
}
}
Das
esp32.core
esp32-Objekt auf oberster Ebene konfiguriert den ESP32-Co-Prozessor. Es enthält zwei Unterobjekte: core und wifi.
| Schlüssel | Typ | Beschreibung |
|---|---|---|
device |
string | CPU-Gerätetyp — teilt dem ESP32 mit, welche Prozessorpersönlichkeit verwendet werden soll. Gültige Werte: "Z80" (picoZ80), "6502" (pico6502), "6512" (pico6512). |
mode |
integer | Standard-Boot-Modus: 0 = Client-(Station-)Modus, 1 = Access-Point-Modus. Dieser Wert wird in NVS persistiert und beim nächsten Boot verwendet, sofern der WiFi-Manager ihn nicht überschrieben hat. |
Das
wifi-Objekt bietet einen Mechanismus, um WiFi-Zugangsdaten und Netzwerkeinstellungen aus der config.json einzuspeisen und damit zu überschreiben, was im NVS gespeichert ist. Dies ist nützlich für die Ersteinrichtung oder zum Bereitstellen einer bekanntermaßen funktionierenden Netzwerkkonfiguration, ohne den Web-WiFi-Manager zu verwenden. Setzen Sie override auf 0, um die Konfigurationsdatei vollständig zu ignorieren und sich auf zuvor persistierte NVS-Einstellungen zu verlassen.
| Schlüssel | Typ | Beschreibung |
|---|---|---|
override |
0/1 | Hauptschalter. 1 = alle unten stehenden Einstellungen anwenden; 0 = diesen Block ignorieren und persistierte NVS-Einstellungen verwenden. |
wifimode |
string | "ap" für Access-Point-Modus (ESP32 erstellt sein eigenes Netzwerk); "client" für Client-/Station-Modus (ESP32 verbindet sich mit einem bestehenden Netzwerk). |
ssid |
string | WiFi-Netzwerkname (SSID), der erstellt (AP-Modus) oder beigetreten (Client-Modus) werden soll. |
password |
string | WiFi-Passphrase für die SSID. |
ip |
string | Feste IP-Adresse (z.B. "192.168.1.192"). Wird in beiden Modi verwendet, wenn dhcp auf 0 steht. |
netmask |
string | Subnetzmaske (z.B. "255.255.255.0"). |
gateway |
string | Standard-Gateway-Adresse (z.B. "192.168.1.1"). |
dhcp |
0/1 | Nur Client-Modus. 1 = Adresse per DHCP beziehen; 0 = die oben angegebene feste ip/netmask/gateway verwenden. |
webfs |
string | Überschreibt das Web-Dateisystem-Stammverzeichnis auf der SD-Karte (Standard "webfs"). Ermöglicht die Bereitstellung alternativer Web-UI-Assets. |
persist |
0/1 | 1 = die aufgelösten WiFi-Einstellungen in NVS zurückschreiben, sodass sie Neustarts überleben, auch nachdem override deaktiviert wurde; 0 = nur für diese Sitzung anwenden. |
| Schlüssel | Typ | Beschreibung |
|---|---|---|
cpufreq |
integer | RP2350-Systemtaktfrequenz in Hz (z.B. 300000000 für 300 MHz). |
psramfreq |
integer | PSRAM-SPI-Taktfrequenz in Hz (z.B. 133000000 für 133 MHz). |
voltage |
float | RP2350-Kernspannung in Volt (z.B. 1.10). Höhere Taktgeschwindigkeiten können eine höhere Spannung erfordern. |
Das
memory-Array definiert die Z80-Speicherbelegung. Jeder Eintrag umfasst einen zusammenhängenden Bereich des 64KB Z80-Adressraums, aufgerundet auf 512-Byte-Blockgrenzen.
| Schlüssel | Typ | Beschreibung |
|---|---|---|
enable |
0/1 | Ob dieser Eintrag aktiv ist. |
addr |
hex string | Startadresse im Z80-Adressraum (z.B. "0x0000"). |
size |
hex string | Größe des Bereichs (z.B. "0x2000" für 8KB). |
type |
string | Blocktyp: PHYSICAL, PHYSICAL_VRAM, PHYSICAL_HW, RAM, ROM, VRAM, FUNC, PTR. |
bank |
integer | PSRAM-Banknummer (0–63) für RAM/ROM/VRAM-Typen. |
tcycwait |
integer | Anzahl zusätzlicher T-Zyklus-Wait-States beim Zugriff. |
tcycsync |
integer | Synchronisation mit steigender T1-Flanke aktivieren. |
task |
string | Optionaler Task-Bezeichner für FUNC-Typ-Blöcke. |
file |
string | SD-Karten-Pfad zu einem ROM-Image, das beim Booten in diesen Block geladen wird. |
fileofs |
integer | Byte-Offset innerhalb der ROM-Image-Datei, ab dem gelesen werden soll. |
"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
}
]
Das
io-Array ordnet Z80-I/O-Port-Bereiche Handlern zu. I/O-Zyklen werden von Speicherzyklen durch das Z80-IORQ-Signal unterschieden, das der PIO-Steuerungs-Zustandsautomat überwacht.
| Schlüssel | Typ | Beschreibung |
|---|---|---|
enable |
0/1 | Ob dieser Eintrag aktiv ist. |
addr |
hex string | Start-I/O-Port-Adresse (z.B. "0xE0"). |
size |
hex string | Anzahl der Ports im Bereich. |
type |
string | PHYSICAL (an Host weiterleiten), FUNC (C-Handler aufrufen). |
func |
string | Handler-Funktionsname für FUNC-Typ. |
"io": [
{
"enable": 1,
"addr": "0xE0",
"size": "0x08",
"type": "FUNC",
"func": "mz700_io"
},
{
"enable": 1,
"addr": "0x00",
"size": "0xE0",
"type": "PHYSICAL"
}
]
Das
drivers-Array bindet benannte Treiberinstanzen an den Z80-Kontext. Jeder Treiber hat ein oder mehrere Interfaces (aufgelistet unter dem "if"-Schlüssel), von denen jedes ROM-Images laden, Adressbereiche umleiten, I/O-Port-Bereiche umleiten und Parameterdateien empfangen kann.
| Schlüssel | Typ | Beschreibung |
|---|---|---|
enable |
0/1 | Ob dieser Treiber geladen wird. |
name |
string | Treibername (muss einem einkompilierten Treiber entsprechen, z.B. "MZ700", "RFS", "TZFS"). |
type |
string | PHYSICAL oder VIRTUAL. |
if |
array | Array von Interface-Objekten (siehe unten). |
Interface-Objekt (if[]):
| Schlüssel | Typ | Beschreibung |
|---|---|---|
enable |
0/1 | Ob dieses Interface aktiv ist. |
name |
string | Interface-Instanzname. |
type |
string | PHYSICAL oder VIRTUAL. |
rom |
array | ROM-Images, die beim Booten in den PSRAM geladen werden. |
addrmap |
array | Adressumleitungsregeln für dieses Interface. |
iomap |
array | I/O-Port-Umleitungsregeln für dieses Interface. |
param |
array | Parameterdateien, die an den Treiber übergeben werden. |
rom[]-Eintrag:
| Schlüssel | Typ | Beschreibung |
|---|---|---|
enable |
0/1 | Ob dieser ROM-Eintrag aktiv ist. |
file |
string | SD-Karten-Pfad zur ROM-Binärdatei. |
loadaddr |
array | Ladeadressen-Deskriptoren (Position, Adresse, Bank, Größe, Wait States). |
addrmap[]-Eintrag:
| Schlüssel | Typ | Beschreibung |
|---|---|---|
enable |
0/1 | Ob diese Zuordnung aktiv ist. |
srcaddr |
hex string | Quelladresse im Z80-Adressraum. |
size |
hex string | Größe des zugeordneten Bereichs. |
dstaddr |
hex string | Zieladresse nach der Umleitung. |
iomap[]-Eintrag:
| Schlüssel | Typ | Beschreibung |
|---|---|---|
enable |
0/1 | Ob diese I/O-Zuordnung aktiv ist. |
srcaddr |
hex string | Quell-I/O-Port. |
size |
hex string | Anzahl der Ports. |
dstaddr |
hex string | Ziel-Port nach der Umleitung. |
16bit |
0/1 | Ob 16-Bit-I/O-Adressierung verwendet wird. |
Damit die maschinenunabhängigen Schnittstellenkarten auf eigenen / experimentellen Platinen verwendet werden können (siehe OpenZ80), lässt sich bei mehreren Karten der Basis-I/O-Port verlagern. Eine verlagerbare Karte liest ihre Basisadresse aus dem
dstaddr ihres iomap-Eintrags (wobei srcaddr auf den authentischen Port der Karte gesetzt ist) und verwendet standardmäßig ihren ursprünglichen Port, wenn kein iomap-Eintrag vorhanden ist. Am einfachsten lässt sich dies über das Feld Basis-I/O-Port auf der Seite GUI-Konfiguration einstellen, das den korrekten iomap-Eintrag für Sie schreibt. Die verlagerbaren Karten und ihre Standard-Basisadressen sind:
| Karte | Standard-Basis | Ports |
|---|---|---|
| MZ-1R12 | 0xF8 | 3 |
| MZ-1R18 | 0xEA | 2 |
| MZ-1R23 | 0xB8 | 2 |
| MZ-1R37 | 0xAC | 2 |
| PIO-3034 | 0x00 | 4 |
| MZ-8BIO3 / MZ-1E24 | 0xB0 | 4 |
| MZ-1E05 | 0xD8 | 7 |
| Celestite | 0x60 | 16 |
"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"
}
]
}
]
}
]
Das folgende ist eine Minimalkonfiguration, die einen MZ-700 mit ROM, 48KB RAM, Host-VRAM und dem WD1773-Floppy-Controller bootet:
{
"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" }] }]
}
]
}
]
}
}
ICE (Debug-Shell)
Der picoZ80 enthält eine integrierte interaktive ICE-(In-Circuit-Emulator-)Debug-Shell über den zweiten USB-CDC-Serial-Kanal. Verbinden Sie einen Terminal-Emulator (115200 Baud, 8N1) mit dem Debug-Serial-Port — er erscheint als zweiter COM/ttyACM-Port, wenn der picoZ80 über USB verbunden ist. Der Shell-Prompt ist
Befehlsreferenz
dbg> .
Die Firmware ist in zwei Varianten verfügbar: ein Standard-Build ohne Debug-Shell und ein DBGSH-Build, der den vollständigen ICE-Debugger enthält. Die DBGSH-Variante wird durch das Suffix _DBGSH im Firmware-Dateinamen gekennzeichnet.
Die Debug-Shell bietet 49 Befehle für die Echtzeit-Inspektion und Steuerung der Z80-CPU-Emulation:
| Befehl | Syntax | Beschreibung |
|---|---|---|
| help | help |
Alle verfügbaren Befehle anzeigen. |
| regs | regs |
Z80-Register ausgeben (AF, BC, DE, HL, IX, IY, SP, PC, I, R, IM, IFF1/2, Flags, HALT, MEMPTR, Zykluszähler). |
| dm | dm <p|f|v|r> <addr> [len] |
Speicher ausgeben. p = physischer Z80-Bus, f = Fetch (M1-Zyklus), v = virtueller PSRAM, r = RP2350-Adressraum. |
| search | search [p|v] <start> <end> <hex..>|"text" |
Speicher nach einem Byte-Muster oder ASCII-Textstring durchsuchen. p = physischer Bus, v = virtueller PSRAM, ohne Angabe = gemappt (folgt der Speicherbelegung). Muster als Hex-Bytes (z.B. ED 4D 00) oder als Quoted-ASCII-String (z.B. "HELLO") angeben. Treffer werden mit 8 Bytes Kontext davor und danach angezeigt. CPU wird bei physischem/gemapptem Zugriff automatisch angehalten. Musterlänge bis 32 Bytes. |
| cmp | cmp [f] <phys> <virt> <len> |
Physischen Bus-Speicher mit virtuellem PSRAM vergleichen. Optionales f verwendet Fetch-(M1-)Zyklen statt Lesezyklen. Meldet Diskrepanzen mit Adressen und Werten. |
| dis | dis [p|v] [addr] [count] |
Z80-Code disassemblieren mit vollständiger Opcode-Dekodierung. |
| asm | asm [addr] |
Interaktiver Z80-Assembler — Mnemonics zeilenweise eingeben, leere Zeile oder . zum Beenden. |
| memmap | memmap [block] |
SRAM-Bank-Zeiger und Speicher-Banking-Layout ausgeben. |
| memptr | memptr [addr] |
PSRAM-memPtr-Tabelle für Adresszuordnung ausgeben. |
| iomap | iomap [port] |
I/O-Port-Handler und speichergemappte I/O-Konfiguration anzeigen. |
| status | status |
Systemübersicht: CPU-Frequenz, PSRAM-Takt, Host-Takt, Emulationsgeschwindigkeit, Betriebszeit. |
| ver | ver |
Firmware-Version und Flash-Partitionsinformationen. |
| drivers | drivers |
Aktive Treiber mit Interface-Details auflisten. |
| hold | hold |
Z80-CPU-Emulation anhalten. |
| release | release |
Z80-CPU-Emulation fortsetzen. |
| go | go |
Ausführung fortsetzen (Hold aufheben; Breakpoints bleiben aktiv). |
| cont | cont |
Alias für go. Ausführung fortsetzen (Hold aufheben; Breakpoints bleiben aktiv). |
| step | step [n] |
Einzelschritt für eine oder n Instruktionen, mit Registeranzeige vor und nach jedem Schritt. |
| bp | bp <addr> |
Breakpoint an der angegebenen Adresse setzen (bis zu 8 gleichzeitige Breakpoints). |
| bc | bc <n|*> |
Breakpoint-Slot n löschen, oder * um alle Breakpoints zu löschen. |
| bl | bl |
Alle aktiven Breakpoints auflisten. |
| wm | wm <[p|v]> <addr> <byte>... |
Bytes in den Speicher schreiben. p = physischer Z80-Bus, v = virtueller PSRAM, ohne Angabe = automatisch (folgt der Speicherbelegung). CPU wird bei physischem/gemapptem Schreiben automatisch angehalten. |
| fill | fill [p|v] <addr> <len> [w|d] <val> |
Speicher mit einem konstanten Wert füllen. p = physisch, v = virtuell, ohne Angabe = automatisch. Standard 8-Bit; w = 16-Bit, d = 32-Bit (Little-Endian). CPU wird bei Bedarf automatisch angehalten. |
| copy | copy <pv|fp|vp> <src> <len> <dst> |
Speicher zwischen physisch und virtuell kopieren. pv = physisch lesen nach virtuell, fp = physischer Fetch nach virtuell, vp = virtuell nach physisch schreiben. CPU wird automatisch angehalten. |
| memtest | memtest <addr> <len> [pattern] |
Physischen Speicher mit drei Durchläufen testen: Schreiben+Lesen, Schreiben+Fetch, verschränkt. Standardmuster: aufsteigende Bytes. Meldet Fehler pro Durchlauf. |
| in | in <port> |
Einen Z80-I/O-Port lesen. |
| out | out <port> <byte> |
In einen Z80-I/O-Port schreiben (CPU muss angehalten sein). |
| trace | trace <on|off|dump [n]|clear|rt|byte ...> |
Ausführungs-Trace aktivieren/deaktivieren, letzte n Einträge ausgeben oder den 512-Einträge-Ringpuffer löschen. rt aktiviert Echtzeit-Trace-Ausgabe auf die Debug-Konsole während der Instruktionsausführung. byte aktiviert Byte-Level-Tracing von Speicher-/IO-Transaktionen. |
| verify | verify <on|off> |
Vollständige Opcode-Fetch-Verifikation umschalten. Bei Aktivierung wird jeder Fetch gegen readPhysicalMem verifiziert (50% Geschwindigkeitsreduktion). Bei Deaktivierung (Standard) werden nur 0x00/0xFF-Opcodes geprüft. |
| fwait | fwait <0-4> |
Zusätzliche Wait States bei M1-(Opcode-Fetch-)Zyklen erzwingen. 0 = aus (Standard). Nützlich zum Debuggen von timing-sensitivem Code. Zeigt den aktuellen Wert an, wenn kein Parameter angegeben wird. |
| iowait | iowait <0-8> |
Zusätzliche Wait States bei I/O-Lese- und Schreibzyklen erzwingen. 0 = aus (Standard). Streckt I/O-Zyklen zur Diagnose von Peripheriegeräten mit langsamen Antwortzeiten. Zeigt den aktuellen Wert an, wenn kein Parameter angegeben wird. |
| corrupt | corrupt [clear] |
Erkannte Fetch-Verfälschungen anzeigen (PC, gefetchter Opcode, verifizierter Opcode). clear setzt das Log zurück. |
| fdctrace | fdctrace <on|off|dump> |
FDC-I/O-Trace aktivieren, deaktivieren oder ausgeben. dump zeigt die letzten 64 WD1773-Registeroperationen aus dem Ringpuffer mit Port, Richtung, Wert und Status. |
| qdtrace | qdtrace <on|off|dump> |
Quick Disk-I/O-Trace aktivieren, deaktivieren oder ausgeben. dump zeigt die letzten 64 Operationen mit Port, Richtung, Wert und Bandposition. |
| piodbg | piodbg [clear] |
RP2350-PIO-Hardware-Diagnose für alle drei PIO-Blöcke (PIO 0, PIO 1, PIO 2) anzeigen. Zeigt FDEBUG-Sticky-Error-Flags, FSTAT, FIFO-Füllstände, Programmzähler pro Zustandsautomat, GPIO-Output-Enable-Zustand und GPIO-Pin-Pegel. clear setzt die FDEBUG-Sticky-Flags zurück. |
| load | load <p|v> <file> <addr> [len] [ofs] |
Eine Datei von der ESP32-SD-Karte in den Z80-Speicher laden. p = auf physischen Bus schreiben, v = in virtuellen PSRAM-Bank 0 schreiben. file ist relativ zu /sdcard/ auf dem ESP32. addr ist die Z80-Startadresse. Wird len weggelassen, wird die gesamte Datei geladen (bis 64KB); falls angegeben, werden so viele Bytes geladen (max 1MB). Optionales ofs ist der Datei-Offset, ab dem gelesen werden soll. CPU wird bei physischen Schreibvorgängen automatisch angehalten. Verwendet PSRAM-Bank 63 als Scratch-Puffer. |
| save | save <p|pf|v> <file> <addr> <len> |
Z80-Speicher in eine Datei auf der ESP32-SD-Karte speichern. p = über physischen Bus lesen, pf = über physischen Fetch (M1-Zyklen) lesen, v = aus virtuellem PSRAM-Bank 0 lesen. file ist relativ zu /sdcard/. addr ist die Z80-Startadresse, len ist die Anzahl zu speichernder Bytes (max 64KB). CPU wird bei physischem Lesen automatisch angehalten. Führt periodischen DRAM-Refresh während physischem Lesen durch. |
| dir | dir [path] |
Dateien auf der ESP32-SD-Karte auflisten. Optionaler Pfad ist relativ zu /sdcard/. |
| echo | echo [on|off] |
Zeichen-Echo umschalten. |
| reset | reset |
Z80-CPU-Reset erzwingen. |
| set | set <reg|flags|memmap|memptr|iomap> <idx> <val> |
Z80-Register, Flags, Speicherbelegung, PSRAM-memPtr oder I/O-Belegungseintrag zur Laufzeit ändern. Ermöglicht Hot-Patching von Registern und Speicher-/IO-Konfiguration ohne Neuladen. |
| hist | hist [n] |
Befehlshistorie anzeigen. Zeigt die letzten n Einträge (Standard: alle). Die Historie wird sitzungsübergreifend über ESP32 NVS aufbewahrt. |
| savehst | savehst |
Befehlshistorie sofort in ESP32 NVS zwangsspeichern. |
| ipl | ipl |
IPL-Reset (BST-Modus) durchführen, indem 8255 PPI Port C Bit 3 umgeschaltet wird. Setzt die Maschine in den Boot-Modus zurück, ohne einen vollständigen Z80-Reset durchzuführen. Nützlich für MZ-80B/MZ-2000/MZ-2500-Maschinen. |
| mmutrace | mmutrace |
Maschinenspezifische Trace-Informationen ausgeben (MMU-Zustand, I/O-Register-Snapshots usw.). Die Ausgabe variiert je nach Persona — jeder Treiber registriert seinen eigenen Trace-Handler. |
| intcount | intcount |
Interrupt-Acknowledge-Zähler und aktuellen Interrupt-Zustand anzeigen. Nützlich zum Debuggen von Interrupt-gesteuerter Software. |
| psync | psync [start end] |
Physischen Speicher mit PSRAM synchronisieren, indem der physische Bus gelesen und in den virtuellen Speicher geschrieben wird. Optionaler Adressbereich; Standard ist der gesamte Adressraum. Nützlich für Diagnosen nach DMA-Operationen. |
| dskimage | dskimage read <filename> [cylinders] [heads] / dskimage write <filename> |
Eine physische Floppy-Disk in eine DSK-Datei auf der SD-Karte abbilden (read), oder eine DSK-Datei von der SD-Karte auf eine physische Floppy schreiben (write). dskimage <filename> verwendet standardmäßig read (abwärtskompatibel). Erkennt Geometrie automatisch, wenn cylinders/heads weggelassen werden. |
| busdiag | busdiag |
Bus-Diagnose einschließlich PIO-Zustand, Signalpegel und Bus-Contention-Status anzeigen. |
| fdcimage | fdcimage |
FDC-Imaging-Status und Fortschritt anzeigen. |
| fdcdiag | fdcdiag |
FDC-Diagnoseinformationen anzeigen (Controller-Zustand, Register-Dump). |
| gadiag | gadiag |
Gate-Array-Diagnoseinformationen anzeigen (Befehlszustand, Interrupt-Routing). |
Breakpoints — bis zu 8 Breakpoints können gleichzeitig aktiv sein. Wenn ein Breakpoint ausgelöst wird, wird die CPU automatisch angehalten und die Trefferadresse angezeigt. Verwenden Sie
go zum Fortsetzen oder step zum Einzelschrittbetrieb ab dem Breakpoint.
Ausführungs-Trace — wenn aktiviert, werden PC, Opcode und Flags-Register jeder ausgeführten Instruktion in einem 512-Einträge-Ringpuffer aufgezeichnet. Verwenden Sie trace dump, um die jüngste Ausführungshistorie mit vollständiger Disassemblierung zu inspizieren.
Speicherzugriffsmodi — dm p liest Speicher über den physischen Z80-Bus (löst echte Hardware-Antworten aus), dm f liest mit Fetch-(M1-)Zyklen, dm v liest direkt aus dem virtuellen PSRAM (keine Busaktivität), und dm r liest den eigenen Adressraum des RP2350 (Flash, SRAM, Peripherie).
Netzwerk
Der picoZ80 unterstützt drei Netzwerkmodi, die zur Build-Zeit über vorgefertigte ESP32-sdkconfig-Dateien auswählbar sind. Jeder Modus bestimmt, wie auf die Web-Oberfläche und die Konfigurationsseiten zugegriffen wird.
Betriebsmodi
| Modus | sdkconfig-Datei | WiFi | USB NCM | Konsole | Webzugriff |
|---|---|---|---|---|---|
| Nur WiFi | sdkconfig.mode_wifi_only |
Ja | Nein | USB Serial/JTAG | Über WiFi AP oder verbundenes Netzwerk |
| WiFi + NCM | sdkconfig.mode_wifi_and_ncm |
Ja | Ja | TinyUSB CDC-ACM | Über WiFi und http://192.168.7.1 |
| Nur NCM | sdkconfig.mode_ncm_only |
Nein | Ja | TinyUSB CDC-ACM | Nur über http://192.168.7.1 |
USB NCM (Network Control Model) stellt einen virtuellen Ethernet-Adapter über den USB-OTG-Port des ESP32 bereit. Wenn der picoZ80 über USB mit einem Host-Computer verbunden wird, sieht der Host eine Standard-Netzwerkschnittstelle. Ein integrierter DHCP-Server auf dem picoZ80 weist dem Host automatisch eine IP-Adresse zu — keine manuelle Konfiguration erforderlich. Die Web-Oberfläche ist dann unter
FCC-/RED-Regulierungshinweis
http://192.168.7.1 erreichbar.
Nur-NCM-Modus ist der empfohlene Standard für Platinen, die ohne WiFi-Zertifizierung ausgeliefert werden. Er bietet die volle Funktionalität der Web-Oberfläche (Konfiguration, Firmware-Updates, Dateiverwaltung, Persona-Auswahl) ohne jegliche Hochfrequenz-Emission. Das WiFi-Antennen-Anpassungsnetzwerk muss auf der Platine nicht bestückt werden.
WiFi + NCM-Modus aktiviert beide Schnittstellen gleichzeitig. Der HTTP-Server bindet an alle Schnittstellen, sodass die Webseiten sowohl über WiFi als auch über die USB-Netzwerkverbindung erreichbar sind. WiFi verbindet sich asynchron, sodass die USB-NCM-Schnittstelle sofort beim Einschalten verfügbar ist.
Um den Modus zu wechseln, kopieren Sie die entsprechende sdkconfig.mode_*-Datei nach sdkconfig im ESP32-Build-Verzeichnis, kompilieren Sie neu und flashen Sie die ESP32-Firmware.
Wichtig: Die picoZ80-Platine wurde nicht zur FCC-(USA) oder RED-(EU)-Zertifizierung als absichtlicher Strahler eingereicht. Im Auslieferungszustand muss die Platine die WiFi-Antennen-Anpassungskomponenten unbestückt haben und die ESP32-Firmware muss mit der Nur-NCM-Konfiguration (
sdkconfig.mode_ncm_only) gebaut sein. In dieser Konfiguration wird keine Hochfrequenzenergie abgestrahlt und die Platine fällt nicht unter die Vorschriften für absichtliche Strahler.
Endnutzer, die WiFi verwenden möchten, können das Antennen-Anpassungsnetzwerk auf der Platine bestücken, die ESP32-Firmware mit sdkconfig.mode_wifi_only oder sdkconfig.mode_wifi_and_ncm bauen und die Platine unter der Hobbyisten-/Experimentalbefreiung betreiben, die in ihrer Rechtsordnung gilt. Jede Partei, die die Platine mit aktiviertem WiFi kommerziell verkaufen möchte, muss zunächst eine FCC- und/oder RED-Zertifizierung für die vollständige Baugruppe erhalten.
Web-Oberfläche
Der ESP32-Co-Prozessor hostet eine Web-Verwaltungsoberfläche, die mit Bootstrap 4 erstellt wurde. Verbinden Sie sich mit dem WiFi-Netzwerk des picoZ80 (oder konfigurieren Sie den Client-Modus, um Ihrem bestehenden Netzwerk beizutreten) und navigieren Sie zu
Dashboard — Status (index.htm)
http://<device-ip>/ — standardmäßig http://192.168.4.1/ im Access-Point-Modus. Im NCM-Modus wird die Web-Oberfläche über die USB-Netzwerkverbindung unter http://192.168.7.1 aufgerufen. Siehe Netzwerk oben für Modus-Details.
Beim ersten Einschalten im WiFi-Modus startet die Platine im AP-Modus. Verwenden Sie die WiFi-Manager-Seite, um den Client-Modus zu konfigurieren und eine feste IP-Adresse in Ihrem Netzwerk zuzuweisen. Alle Seiten teilen eine gemeinsame Navigationsleiste auf der linken Seite, die mit einem Klick Zugriff auf Status, Config-Editor, Config-GUI, Dateiverwaltung, Einstellungen (Firmware → ESP32 / RP2350, WiFi-Manager) und Persona bietet. Im Nur-NCM-Modus ist die WiFi-Manager-Seite nicht vorhanden und die Navigationsleiste zeigt dieselben Seiten abzüglich des WiFi-Managers.
Die Startseite zeigt den Live-Status der Platine in drei Panels:
- WiFi-Konfiguration / Netzwerkkonfiguration
- in WiFi-Modi zeigt dieses Panel die aktuelle SSID, die zugewiesene IP-Adresse, Subnetzmaske und Gateway. Im Nur-NCM-Modus ist dieses Panel mit Netzwerkkonfiguration betitelt und zeigt stattdessen den USB-NCM-Netzwerkstatus (IP-Adresse, Subnetzmaske) — es gibt keine SSID oder WiFi-bezogene Informationen. Der Platinenname (tzpuPico) und der Copyright-String werden als Template-Variablen vom ESP32-Webserver bereitgestellt. - Versionsinformationen
- ESP32-Partitionstabelle mit allen OTA-Slots inklusive Typ, Sub-Typ, Flash-Adresse, Größe, Firmware-Version, Build-Zeitstempel und welcher Slot aktuell läuft. Dies erleichtert die Bestätigung, welche Firmware nach einem OTA-Update aktiv ist. - RP2350-Partitionen
- die RP2350-Flash-Partitionstabelle mit Partitionsnummer, Adresse, Größe, Prüfsumme, Aktiv-/Running-Flag, Lizenz, Autor, Beschreibung, Version, Build-Datum und Copyright — ein vollständiger Überblick über den RP2350-Firmware-Zustand neben den ESP32-Informationen.
- Aktionsmenü
- Floppy Disk 1 / 2 wechseln — ein neues DSK-Image von der SD-Karte auswählen und in den virtuellen WD1773-Floppy-Controller-Slot 1 oder Slot 2 einlegen, ohne neu zu starten. Der aktuell geladene Disk-Image-Dateiname wird neben jedem Eintrag angezeigt (oder "none", wenn kein Image geladen ist).
- QD-Disk wechseln — das aktive QuickDisk-Image im laufenden Betrieb austauschen. Der aktuell geladene QD-Image-Dateiname wird neben dem Eintrag angezeigt.
- RP2350-Konfiguration neu laden — einen Neulade-Befehl über die ESP32–RP2350 UART an den RP2350 senden; der RP2350 parstconfig.jsonerneut und wendet die Speicherbelegung und Treiberkonfiguration ohne einen vollständigen Stromzyklus neu an. - Neustart-Menü
- ESP32 — Soft-Reboot des ESP32-Co-Prozessors (startet Webserver und WiFi-Stack neu, RP2350 bleibt unberührt).
- RP2350B — RP2350-Prozessor zurücksetzen (führt den Bootloader erneut aus und lädt den aktiven Firmware-Slot neu, Host-CPU wird während des Resets pausiert).
- Host — die Reset-Leitung des Host-Computers aktivieren und den Retro-Computer im Z80-Sockel neu starten, ohne die picoZ80-Platine selbst zu beeinträchtigen.
- IPL-Reset — einen IPL-(Initial Program Load-)Reset durchführen, indem 8255 PPI Port C Bit 3 umgeschaltet wird, und die Maschine in den Boot-Modus (BST) zurückversetzen. Verfügbar bei MZ-80B-, MZ-2000-, MZ-2200- und MZ-2500-Personas — entspricht dem Drücken der IPL-Taste an der Original-Hardware.
- RP2350 UF2 Boot — den RP2350 über den benutzerdefinierten Bootloader in den ROM-UF2-USB-Boot-Modus zwingen. Der ESP32 setzt den RP2350 mit gehaltenem BOOT-Pin zurück und sendet dann eine Magic-ID über UART, die den Bootloader veranlasst,reset_usb_boot()aufzurufen. Der RP2350 meldet sich als USB-Massenspeichergerät für UF2-Drag-and-Drop-Flashing. Dies ist die primäre Wiederherstellungsmethode, wenn die Hauptanwendung defekt ist (z.B. fehlerhafte Takt-/Spannungseinstellungen) — der benutzerdefinierte Bootloader läuft mit sicheren Standardwerten und bleibt reaktionsfähig.
- RP2350 UF2 Boot (App) — die laufende RP2350-Anwendung auffordern, über SPI-Befehl in den UF2-USB-Boot-Modus zu wechseln. Dies ist ein Fallback für Situationen, in denen der Bootloader selbst ersetzt werden muss — die laufende Anwendung ruftreset_usb_boot()direkt auf. Funktioniert nur, wenn die Anwendung läuft und auf SPI-Befehle reagiert.

Die Konfigurationseditor-Seite bietet volle Bearbeitungskontrolle über die JSON-Konfigurationsdatei.
Ändern Sie die Konfiguration mit dem WYSIWYG-Editor, speichern Sie nach Bedarf und klicken Sie auf Apply, um die
Konfiguration neu zu verarbeiten.
Die SD-Karte hält automatische nummerierte Sicherungskopien jeder gespeicherten Konfiguration (
config.json;1,
config.json;2, … wobei die höchste Nummer die aktuellste ist), sodass es immer möglich ist, auf eine
vorherige funktionierende Konfiguration zurückzusetzen. Bearbeitete Konfigurationen werden auf der SD-Karte gespeichert; ein Klick auf Apply oder eine "Reload"-Menüaktion
sendet dann einen Neulade-Befehl an den RP2350 über die ESP32–RP2350-UART, wodurch der RP2350 die neue Konfiguration
erneut parst und anwendet und der ESP32 seine Konfiguration parst und neu lädt.

Die GUI-Konfigurationsseite bietet einen grafischen, formularbasierten Editor für die picoZ80-Konfiguration, der den rohen JSON-Config-Editor ergänzt. Anstatt JSON direkt zu bearbeiten, werden alle Einstellungen als beschriftete Eingabefelder, Dropdown-Menüs und bearbeitbare Tabellen dargestellt. Änderungen werden in
config.json auf der SD-Karte gespeichert (die bestehende Datei wird vor dem Speichern automatisch gesichert). Für erweiterte Bearbeitung steht der Config-Editor weiterhin für direkte JSON-Manipulation zur Verfügung.
Die Seite ist in vier Tabs organisiert:
RP2350 Global — globale Kerneinstellungen, die für beide Firmware-Partitionen gelten, sofern nicht auf Partitionsebene überschrieben:
- Kernspannung — RP2350-Kernspannung in Volt (z.B. 1,10 V).
- CPU-Frequenz (MHz) — RP2350-Taktgeschwindigkeit. Der gültige Bereich wird neben dem Feld angezeigt.
- PSRAM-Frequenz (MHz) — PSRAM-SPI-Taktfrequenz. Höhere Werte verbessern die Emulationsgeschwindigkeit, können aber bei einigen Platinen die Stabilität beeinträchtigen.

Partition 1 / Partition 2 — partitionsspezifische Konfiguration. Jeder Partitions-Tab hat dasselbe Layout:
- Kerneinstellungen — partitionsspezifische Überschreibungen für Kernspannung, CPU-Frequenz und PSRAM-Frequenz. Falls gesetzt, haben diese Vorrang vor den globalen Werten für diese Partition.
- Speicherbereiche — eine bearbeitbare Tabelle, die die Z80-Speicherbelegung definiert. Jede Zeile spezifiziert einen Speicherblock mit: Hex-Adresse, Größe, Typ (ROM, RAM, PHYSICAL oder FUNC), T-States (Wait States), Bank (PSRAM-Banknummer), Track (T-Zyklus-Sync-Flag), Datei (ROM-Image-Dateiname auf der SD-Karte), Datei-Offset und ein Load-Kontrollkästchen. Zeilen können mit den Schaltflächen Speicherbereich hinzufügen und Löschen hinzugefügt oder entfernt werden.
- I/O-Bereiche — eine bearbeitbare Tabelle, die die Z80-I/O-Port-Belegung definiert. Jede Zeile spezifiziert: Adresse, Größe, Typ und Funktion (den Treiber-Handler). Zeilen können nach Bedarf hinzugefügt oder entfernt werden.
- Treiber — listet die aktiven Peripherietreiber (z.B. MZ80AFI, RFS, MZ-1E30, Celestite) mit Aktivieren-/Deaktivieren-Schaltern auf. Die Schaltfläche Treiber hinzufügen zeigt ein Dropdown der für die laufende Firmware gültigen Treiber — die Seite liest die Persona-Zeichenkette der Firmware und bietet nur die Treiber für diese Serie an (Sharp, Amstrad, Tatung oder Open). Jeder Treiber listet seine System-ROMs (treiberseitige ROM-Images, die die ROMs des Hosts überschreiben) und seine Interfaces auf; Floppy-Controller, QuickDisk, RAM/ROM-Karten, SASI-Festplatte, RS-232C-Serienkarten und LAN-Schnittstellen können hinzugefügt werden, und die ROM-Dateien, Disk-Images und Parameter jeder Schnittstelle können inline konfiguriert werden.
- Basis-I/O-Port — für die verlagerbaren Schnittstellenkarten (MZ-1R12, MZ-1R18, MZ-1R23, MZ-1R37, PIO-3034, MZ-8BIO3, MZ-1E24, MZ-1E05, Celestite) wird ein einzelnes Hex-Feld Basis-I/O-Port angezeigt, das mit der authentischen Basis der Karte vorbelegt ist. Ändern Sie es, um die Ports der Karte auf einer eigenen Platine zu verschieben (siehe Verlagerbare Schnittstellen-I/O-Ports); die GUI schreibt automatisch den passenden
iomap-Eintrag und lässt ihn weg, wenn Sie den Wert auf dem Standard belassen. - Port-Parameter — die RS-232C-Serienkarten (MZ-8BIO3 / MZ-1E24) akzeptieren außerdem einen numerischen Port-Parameter für ihren Basis-I/O-Port (Standard 0xB0; Kanal A → USB CDC 2, Kanal B → USB CDC 3).
- Basis-I/O-Port — für die verlagerbaren Schnittstellenkarten (MZ-1R12, MZ-1R18, MZ-1R23, MZ-1R37, PIO-3034, MZ-8BIO3, MZ-1E24, MZ-1E05, Celestite) wird ein einzelnes Hex-Feld Basis-I/O-Port angezeigt, das mit der authentischen Basis der Karte vorbelegt ist. Ändern Sie es, um die Ports der Karte auf einer eigenen Platine zu verschieben (siehe Verlagerbare Schnittstellen-I/O-Ports); die GUI schreibt automatisch den passenden


ESP32 — ESP32-Co-Prozessor-Einstellungen:
- Core — ESP32-Gerätetyp (z.B. S3S).
- Netzwerkschnittstellen — Aktivieren-/Deaktivieren-Steuerungen für sowohl WiFi als auch USB NCM-Netzwerk:
- WiFi aktivieren — Kontrollkästchen zum Aktivieren oder Deaktivieren von WiFi (erfordert Neustart; ignoriert, wenn WiFi nicht in die Firmware kompiliert ist).
- NCM aktivieren — Kontrollkästchen zum Aktivieren oder Deaktivieren von USB NCM-Netzwerk (erfordert Neustart).
- NCM-Wiederholungen — maximale Verbindungswiederholungszyklen (0 = endlos wiederholen, 5–1000 = maximale Versuche).
- NCM-Wiederholungszeitraum — Verzögerung zwischen Wiederholungen in Sekunden (0 = zunehmende Rückstellung von 1s bis 60s, 1–120 = festes Intervall).
- NCM-IP-Adresse — die USB-NCM-Gateway-IP-Adresse (Standard: 192.168.7.1). Beim Anschluss von zwei picoZ80-Platinen an denselben Host muss jede ein anderes Subnetz verwenden (z.B. 192.168.7.1 und 192.168.8.1). Änderungen werden nach Neustart wirksam und in NVS persistiert.
- NCM-Subnetzmaske — die USB-NCM-Subnetzmaske (Standard: 255.255.255.0). Änderungen werden nach Neustart wirksam.
- USB-Produktname — der USB-Geräte-Produktstring, der dem Host-Betriebssystem gemeldet wird. macOS verwendet dies als NCM-Netzwerkschnittstellen-Bezeichnung. Jede Platine generiert automatisch einen eindeutigen Namen aus ihrer MAC-Adresse (z.B. "picoZ80-3C4E"); hier überschreiben, um einen benutzerdefinierten Namen zu setzen (z.B. "picoZ80-MZ700"). Leer lassen für automatische Generierung. Änderungen werden nach Neustart wirksam.
- WiFi-Konfiguration — SSID, Passwort, IP-Adresse, Subnetzmaske, WiFi-Modus (Access Point oder Client), DHCP (aktiviert oder deaktiviert), WebFS-Verzeichnispfad, Polling-Zeitraum und TX-Leistung. Diese Einstellungen spiegeln die WiFi-Manager-Seite wider, sind aber hier als Teil der Gesamtkonfiguration bearbeitbar.

Klicken Sie auf Konfiguration speichern, um die Änderungen in
Dateiverwaltung (filemanager.htm)
config.json auf der SD-Karte zu schreiben (die vorherige Version wird automatisch gesichert) und automatisch einen Neulade-Befehl an den RP2350 zu senden, der die neue Konfiguration ohne einen vollständigen Stromzyklus anwendet. Klicken Sie auf Neu laden, um die aktuelle config.json von der SD-Karte erneut einzulesen — nützlich, wenn Sie einen Fehler gemacht haben und Ihre Änderungen verwerfen und vom letzten gespeicherten Zustand neu beginnen möchten.
Die Dateiverwaltung bietet einen vollständigen webbasierten Dateibrowser für die SD-Karte mit einem Verzeichnislisting-Layout zum Anzeigen der Dateien
auf der SD-Karte.
Sie ist für die allgemeine SD-Karten-Wartung vorgesehen: Hochladen von ROM-Images, Floppy-Disk-Images (DSK), QuickDisk-Images (QD), RAM-Disk-Images und Web-Dateisystem-Updates, ohne die Karte entfernen zu müssen.
Jeder Eintrag hat Aktionsschaltflächen zum Kopieren, Löschen, Herunterladen oder Bearbeiten von Textdateien, und eine Datei auswählen-Upload-Schaltfläche oben ermöglicht die Übertragung neuer Dateien vom PC. Die Verzeichnisnavigation ermöglicht das Absteigen in Unterverzeichnisse wie
roms/, dsk/, qd/ und ram/.
Das Hochladen von tar- oder gzip-Dateien führt dazu, dass die tar- oder gzip-(oder tar.gz-)Datei automatisch im aktuellen SD-Verzeichnis
entpackt und extrahiert wird.
Mehrere Dateien können über die Kontrollkästchen in der linken Spalte (oder das "Alle auswählen"-Kontrollkästchen in der Kopfzeile) ausgewählt werden. Wenn ein oder mehrere Elemente ausgewählt sind, erscheinen die Schaltflächen N Elemente herunterladen und Ausgewählte löschen in der Panel-Kopfzeile. Die Download-Funktion ruft jede Datei sequenziell mit einem Fortschritts-Modal ab — Verzeichnisse werden automatisch als tar-Archive heruntergeladen. Eine SD sichern-Schaltfläche lädt den gesamten SD-Karten-Inhalt als einzelnes Archiv auf den lokalen Computer herunter. Diese Funktionen sind besonders nützlich, wenn der picoZ80 in einem Host-Rechner eingebaut ist und das physische Entfernen der SD-Karte unpraktisch ist.

Die Persona-Seite konfiguriert die aktive Maschinenpersönlichkeit unabhängig für jede der zwei RP2350-Firmware-Partitionen. Jede Partition hat ihre eigene Spalte mit Radiobuttons, die jeden unterstützten Sharp-MZ-Maschinentyp abdecken:
- Basic CPU — reine Z80-Emulation ohne maschinenspezifische Treiber; nützlich für allgemeine Z80-Entwicklung.
- MZ-80A und MZ-80B — Sharp MZ-80-Serie (1Z-013A Monitor-ROM, MZ-80-Tastatur, Standard-Speicherbelegung).
- MZ-700 — Sharp MZ-700 mit bankgeschaltetem VRAM, Tastaturcontroller und optionalen Floppy/QuickDisk-Treibern.
- MZ-800 — Sharp MZ-800 mit erweiterten Videomodi und QuickDisk-Unterstützung.
- MZ-1500 — Sharp MZ-1500 mit QuickDisk und optionaler Floppy.
- MZ-2000, MZ-2200, MZ-2500 — spätere Sharp MZ-Serie mit hochauflösendem Video und erweitertem Speicher.
config.json auf die SD-Karte (die aktuelle Datei wird vorher gesichert) und löst ein Neuladen der Konfiguration aus. Da jede Firmware-Partition eine andere Persona halten kann, kann die Platine zwischen beispielsweise einer MZ-700-Persönlichkeit auf Partition 1 und einer MZ-80A-Persönlichkeit auf Partition 2 umgeschaltet werden, ohne die SD-Karte zu bearbeiten.
Die OpenZ80-Experimentier-Persona (siehe OpenZ80 — Experimentier-Persona) ist ein eigener Firmware-Build und keine Radio-Option auf dieser Seite: Flashen Sie die OpenZ80-Firmware über die Firmware-Update-Seiten auf eine Partition und konfigurieren Sie anschließend ihre Schnittstellenkarten und deren Basis-I/O-Ports auf der Seite GUI-Konfiguration. Für einen einfachen im Sockel steckenden Z80 ohne zusätzliche Ressourcen auf einer unterstützten Maschine bleibt die oben genannte Option Basic CPU verfügbar.

Die ESP32-OTA-Seite zeigt das vollständige Software-Inventar des ESP32 an, bevor ein Firmware-Upload akzeptiert wird:
- Module-Panel
- zeigt die Version jeder ESP32-Softwarekomponente: die Haupt-ESP32-Anwendung, die NVS-(Non-Volatile-Storage-)Bibliothek, den WiFi-Stack, das FilePack (Web-Dateisystem-Paketersteller) und das WebFS (In-Flash-Web-Dateisystem). Dies erleichtert die Bestätigung, dass alle Komponenten nach einem Update konsistent sind. - ESP32-Partitionen-Panel
- zeigt die vollständige ESP32-OTA-Partitionstabelle (otadata, nvs, phy_init, ota_0, ota_1) mit Adressen, Größen, Firmware-Versionen, Build-Zeitstempeln und welcher OTA-Slot aktuell aktiv ist (markiert mit "Yes"). - ESP32-Firmware-Upload-Panel
- akzeptiert die ESP32-Binärdatei (.bin), die vom ESP-IDF-Build erzeugt wurde. Nach dem Upload startet der ESP32 in die neue Firmware neu und der alte Slot wird als Fallback beibehalten. - FilePack-Upload-Panel
- lädt ein versioniertes FilePack-Archiv auf die SD-Karte hoch. Ein FilePack bündelt alle statischen ESP32-Web-Assets (HTML, CSS, JavaScript-Templates und Zusatzdateien) in ein einzelnes verteilbares Archiv. Beim Upload entpackt der ESP32 das Archiv in das SD-Karten-Web-Dateisystem-Verzeichnis; jede Datei, die ersetzt wird, wird automatisch umbenannt, um ihre vorherige Versionsnummer einzuschließen (z.B.webfs→webfs.2.80), wodurch die alte Version für ein Rollback erhalten bleibt. Dies entspricht der VAX/VMS-Stil-Versionierung, die anderswo auf der SD-Karte verwendet wird, bei der jede aufeinanderfolgende Revision einer bearbeitbaren Datei mit einem numerischen Suffix aufbewahrt wird:config.json;1,config.json;2usw. — um sicherzustellen, dass keine Bearbeitung jemals stillschweigend überschrieben wird.

Die RP2350-OTA-Seite verwaltet die zwei RP2350-Firmware-Partitionen:
- RP2350-Partitionen-Panel
- listet alle drei Partitionen auf: Partition 0 (Bootloader), Partition 1 (erster Anwendungs-Slot, z.B. "Z80 CPU Emulator") und Partition 2 (zweiter Slot). Jede Zeile zeigt die Flash-Adresse, Größe, Prüfsumme, Aktiv-/Running-Flag, Lizenz, Autor, Beschreibung, Version und Build-Datum. Die aktuell laufende Partition ist in der Aktiv-Spalte mit "Yes" markiert. - RP2350-Firmware-Upload-Panel
- akzeptiert eine reine Binär-.bin-Firmware-Datei ausfw/bin/. UF2 wird hier nicht verwendet — Anwendungspartitionen befinden sich an nicht-standardmäßigen Flash-Adressen, die UF2 nicht ausdrücken kann, daher verwendet der OTA-Transfer rohes Binärformat. Verwenden Sie die Radiobuttons Partition 1 / Partition 2, um den Ziel-Slot auszuwählen. Zwei zusätzliche Kontrollkästchen sind verfügbar: App-Konfiguration löschen löscht die ROM-Images und die minifizierte JSON-Konfigurationspartition, die dem Ziel-Slot zugeordnet ist (nützlich beim Upgrade auf eine Firmware-Version mit inkompatiblem Konfigurationsschema), und Flash-Header löschen setzt den Flash-Partitions-Header auf Werkseinstellungen zurück, wobei die Partitionstabelle von Grund auf neu aufgebaut wird, während die Bootloader-Konfiguration erhalten bleibt. Der Upload wird vor der Aktivierung der neuen Partition per Prüfsumme verifiziert. - RP2350-Aktive-Partition-Panel
- schaltet die aktive Partition unabhängig um, ohne neue Firmware hochzuladen. Die Auswahl einer Partition hier löst einen automatischen Neustart in den gewählten Slot aus — nützlich zum Umschalten zwischen zwei vorgeladenen Firmware-Varianten (z.B. Z80 und einem Test-Build) ohne Dateitransfer.

Hinweis: Die WiFi-Manager-Seite ist nur verfügbar, wenn die ESP32-Firmware mit aktiviertem WiFi gebaut wurde (
sdkconfig.mode_wifi_only oder sdkconfig.mode_wifi_and_ncm). Im Nur-NCM-Modus ist diese Seite nicht in der Navigation vorhanden — die Netzwerkverbindung wird automatisch über USB NCM bereitgestellt, ohne dass eine Benutzerkonfiguration erforderlich ist.
Der WiFi-Manager konfiguriert, wie der picoZ80 eine Verbindung zu einem drahtlosen Netzwerk herstellt. Das obere Panel zeigt die aktuell aktive WiFi-Konfiguration (SSID, zugewiesene IP, Subnetzmaske und Gateway). Das Formular "WiFi konfigurieren" darunter zeigt alle Einstellungen:
- WiFi-Modus
- Access Point: der picoZ80 sendet seine eigene SSID und Sie verbinden sich direkt damit (nützlich bei der Ersteinrichtung oder wenn kein Infrastrukturnetzwerk verfügbar ist). Client: der picoZ80 tritt einem bestehenden WiFi-Netzwerk als Station bei. - SSID und Passwort
- der Name und die Passphrase des Netzwerks, dem beigetreten (Client-Modus) oder das gesendet werden soll (AP-Modus). - DHCP-Modus
- Aktiviert: die Platine fordert eine Adresse vom DHCP-Server des Netzwerks an. Deaktiviert: eine statische IP, Subnetzmaske und Gateway verwenden, wie in den folgenden Feldern eingegeben. Eine feste IP wird empfohlen, damit die Adresse der Web-Oberfläche immer vorhersagbar ist.

Die zwei Dropdown-Menüs in der oberen rechten Navigationsleiste sind auf jeder Seite der Web-Oberfläche verfügbar und bieten schnellen Zugriff auf Laufzeitoperationen und System-Reset-Funktionen, ohne von der aktuellen Seite weg zu navigieren.
Das Aktionsmenü (Zahnrad-Symbol) bietet Laufzeitoperationen, die sofort ohne Neustart wirksam werden: Tausch von Floppy-Disk- oder QuickDisk-Images im laufenden Betrieb und Auslösen eines Live-Konfigurations-Neuladens auf dem RP2350. Die aktuell geladenen Disk-Image-Dateinamen werden neben jedem Eintrag angezeigt, sodass der Bediener auf einen Blick sehen kann, welche Images eingelegt sind.
Das Neustart-Menü (Rotationssymbol) bietet gezielte Reset-Optionen für jedes Subsystem — ESP32, RP2350, Host-Computer und IPL — plus zwei UF2-Wiederherstellungsoptionen zum Neuflashen des RP2350 über USB-Massenspeicher, wenn die Platine physisch unzugänglich in einem Host-Rechner eingebaut ist. Die zwei UF2-Einträge bieten ergänzende Wiederherstellungspfade: der Bootloader-Weg funktioniert auch dann, wenn die Hauptanwendung defekt ist, während der App-Weg auch dann funktioniert, wenn der Bootloader selbst ersetzt werden muss.
——————————————————————————————————–
Referenzseiten
Die folgende Tabelle enthält alle Websites, die beim Design und bei der Programmierung des picoZ80 herangezogen wurden.
| Website | Sprache | Beschreibung |
|---|---|---|
| RP2350 Datasheet | Englisch | Offizielle technische Referenz und Datenblatt des Raspberry Pi RP2350. |
| Pico SDK | Englisch | Raspberry Pi Pico C/C++ SDK — Build-System und Hardware-Abstraktionsschicht, die von der picoZ80-Firmware verwendet wird. |
| Z80 CPU User Manual | Englisch | Zilog Z80 CPU-Familienhandbuch — Bus-Timing, Befehlssatz und Signalbeschreibungen. |
| ESP-IDF | Englisch | Espressif IoT Development Framework, verwendet für die ESP32-Co-Prozessor-Firmware. |
| Sharp MZ Series | Englisch | Community-Ressource für Sharp MZ-Computer-Hardware, -Software und technische Dokumentation. |
Handbücher und Datenblätter
Die folgende Tabelle enthält alle Datenblätter und Handbücher, die beim Design und bei der Programmierung des picoZ80 herangezogen wurden.
| Datenblatt | Sprache | Beschreibung |
|---|---|---|
| RP2350 | Englisch | Raspberry Pi RP2350-Mikrocontroller-Datenblatt. |
| ESP32-S3 | Englisch | Espressif ESP32-S3 SoC-Datenblatt — WiFi/BT-Co-Prozessor auf der picoZ80-Platine. |
| APS6404L PSRAM | Englisch | 8MB SPI PSRAM-Datenblatt — der zentrale erweiterte RAM für Speicher-Banking. |
| W25Q128 Flash | Englisch | Winbond 16MB SPI NOR Flash-Datenblatt — speichert Firmware und ROM-Images. |
| TLV62590 | Englisch | Texas Instruments 5V→3,3V synchroner Buck-Converter, der den picoZ80 vom VCC-Pin des Z80-DIP-40-Sockels versorgt. |
| CH334F | Englisch | CH334F 4-Port USB 2.0-Hub-Controller — bietet USB-Hub-Funktionalität für Firmware-Updates. |
Projektvorschau
Frühe Entwicklungsvorschauen des picoZ80-Projekts wurden auf X (ehemals Twitter) geteilt. Der folgende Beitrag zeigt die Platine bei ihrem ersten Betrieb:
https://x.com/engineerswork1/status/1953171627065188841
Demonstrationsvideos
picoZ80 mit RFS (ROM Filing System) — Demo 1
Der picoZ80, eingebaut in einen Sharp MZ-700, mit der ROM Filing System (RFS)-Persona. Das Video demonstriert die virtuellen Disk- und Speicher-Banking-Fähigkeiten der Platine.
Ein kurzer Clip, der eine Z80-CPU-Tester-Platine beim Testen des picoZ80 zeigt. Der Tester verifiziert, dass der picoZ80 ein echter Z80 ist, identifiziert ihn als NMOS Z80 und führt Testcode mit 8 MHz aus, um den korrekten Betrieb zu bestätigen.
Der picoZ80 v2.5, eingebaut in einen Sharp MZ-80A, beim Laden eines Programms von einem physischen Kassettenband. Das Laden von Kassetten ist extrem zeitkritisch — der Z80 muss den seriellen Datenstrom von der Bandgeräte-Hardware in Echtzeit bit-bangen, ohne Spielraum für Timing-Fehler. Dieses Video demonstriert, dass der picoZ80 das kritische CMT-Timing identisch zu einem echten Z80 handhabt.
Der picoZ80 v2.5 in einem Sharp MZ-80A beim Lesen von einem echten Floppy-Disk-Controller und physischen Diskettenlaufwerk. Der Floppy-Disk-Zugriff erfordert präzise, zeitkritische Interaktion zwischen dem Z80 und der WD1773 FDC-Hardware — DRQ muss innerhalb enger Timing-Fenster bedient werden, sonst gehen Daten verloren. Dieses Video demonstriert, dass der picoZ80 mit zeitkritischer Echtzeit-Hardware genauso interagiert wie ein echter Z80.
Der picoZ80 v2.5a, eingebaut in einen Sharp MZ-2000, läuft vollständig physisch — alle ROM-, RAM- und VRAM-Zugriffe werden an die echte MZ-2000-Hardware durchgeleitet. Der Floppy-Disk-Controller ist virtualisiert, wobei der picoZ80 den MB8866 FDC emuliert und Disk-Images von der SD-Karte bedient, während der Rest der Maschine auf seiner Original-Hardware läuft.
Kommerzielle Nutzungsbeschränkung
Keine kommerzielle Nutzung ohne ausdrückliche schriftliche Genehmigung gestattet.
Das picoZ80-Hardwaredesign (Schaltpläne, PCB-Layout, KiCad-Dateien), die Firmware und alle zugehörige Software werden ausschließlich für den persönlichen, bildungsbezogenen und nicht-kommerziellen Gebrauch zur Verfügung gestellt. Kein Teil dieses Designs — einschließlich, aber nicht beschränkt auf das PCB-Artwork, die Stückliste, Firmware-Binärdateien, den Quellcode oder die Dokumentation — darf ohne die ausdrückliche schriftliche Genehmigung des Autors (Philip D. Smart) verwendet, reproduziert, hergestellt, verkauft oder in ein kommerzielles Produkt oder eine Dienstleistung eingebunden werden.
Um eine kommerzielle Lizenz anzufordern oder erlaubte Nutzungen zu besprechen, kontaktieren Sie den Autor bitte über die Website eaw.app.
Danksagungen
Das picoZ80-Projekt baut auf der Arbeit mehrerer Einzelpersonen und Open-Source-Projekte auf. Ihre Beiträge werden dankbar anerkannt.
- Manuel Sainz de Baranda y Goñi
Autor der Z80 C-Sprache Z80-CPU-Emulatorbibliothek (github.com/redcode/Z80). Dieser hochpräzise, zyklusgenaue Z80-Emulatorkern wird von der picoZ80-Firmware verwendet, wenn Z80-Instruktionen intern auf dem RP2350 ausgeführt werden, und bietet präzises Flag-Verhalten und Unterstützung undokumentierter Opcodes. Die Bibliothek wird unter den Bedingungen der GNU General Public License v3 verwendet. - Raspberry Pi Ltd
Autoren des Pico SDK und der RP2350-Hardware. Der PIO-Assembler, das C SDK, die CMake-Toolchain-Integration und der RP2350B-Silizium machen die zyklusgenaue Busschnittstelle möglich. - Espressif Systems
Autoren des ESP-IDF-Frameworks und der ESP32-Hardware. Der ESP32-Co-Prozessor, WiFi-Stack, die OTA-Bibliothek und das NVS-Speicher-Framework bilden die Grundlage der Web-Verwaltungsoberfläche. - Philip Smart
Hardwaredesign (KiCad-Schaltpläne und PCB-Layout), RP2350 PIO-Firmware, ESP32-Webanwendung, JSON-Konfigurationssystem, Sharp MZ-Maschinenpersona-Treiber und die gesamte Projektdokumentation. - Grok (xAI)
KI-Assistent, der wertvolle Hilfe beim Debugging der PIO-Zustandsautomaten leistete — insbesondere bei der Diagnose von Timing-Grenzfällen und zyklussynchronen Bus-Interaktionsproblemen in den RP2350 PIO-Programmen. - Claude (Anthropic)
KI-Assistent, der in mehreren Bereichen zu diesem Projekt beiträgt: Erstellung und Strukturierung der Projektdokumentation, Analyse der FSPI/UART-Schnittstelle zwischen RP2350 und ESP32 und Bereitstellung von Firmware-Verbesserungsempfehlungen sowie laufende Firmware-Entwicklungsunterstützung.
Lizenzen
Das picoZ80-Projekt besteht aus mehreren Komponenten, die jeweils unter ihrer eigenen Lizenz stehen:
Kurz gesagt: Die Firmware und Software, die Sie aus dem Quellcode dieses Projekts erstellen, sind Open Source unter der GPL v3; die Hardware-Designs und die Dokumentation sind unter CC BY-NC-SA 4.0 lizenziert (nur nicht-kommerzielle Nutzung — kommerzielle Lizenzierung auf Anfrage verfügbar); Drittanbieter-Bibliotheken behalten ihre eigenen Lizenzen wie oben aufgeführt. Siehe die Dateien
| Komponente | Lizenz |
|---|---|
| picoZ80 RP2350-Firmware (PIO, C-Quellen) | GNU General Public License v3 |
| picoZ80 ESP32-Firmware und Web-Oberfläche | GNU General Public License v3 |
| Z80 CPU-Emulatorbibliothek (Manuel Sainz de Baranda y Goñi) | GNU General Public License v3 |
| KiCad-Hardwaredesign-Dateien (Schaltpläne, PCB, Gerber) | Creative Commons BY-NC-SA 4.0 |
| Dokumentation und Benutzerhandbücher | Creative Commons BY-NC-SA 4.0 |
| Raspberry Pi Pico SDK | BSD 3-Clause |
| ESP-IDF-Framework | Apache License 2.0 |
| Bootstrap 4 (Web-Oberfläche) | MIT License |
LICENSE und NOTICE im Repository für vollständige Details.
Lizenzbestimmungen
Copyright © 2019–2026 Philip Smart. Alle Rechte vorbehalten.
Hardware-Designs — CC BY-NC-SA 4.0
Alle Hardware-Designs (KiCad-Schaltpläne, PCB-Layouts, Gerber-Fertigungsdateien, Stücklisten) sind unter der Creative Commons Namensnennung-Nicht kommerziell-Weitergabe unter gleichen Bedingungen 4.0 International Lizenz lizenziert. Sie dürfen die Designs nur für nicht-kommerzielle Zwecke teilen und anpassen, vorausgesetzt, Sie geben angemessene Anerkennung und verteilen alle Modifikationen unter derselben Lizenz. Kommerzielle Herstellung oder Verkauf erfordert eine separate Lizenz — bitte kontaktieren Sie info@eaw.app. Firmware & Software — GNU GPL v3
Die Firmware und der Software-Quellcode sind freie Software unter der GNU General Public License v3. Sie dürfen den Code unter den Bedingungen der GPL v3 weiterverteilen und modifizieren. Alle verteilten Modifikationen müssen ebenfalls unter GPL v3 lizenziert sein und der Quellcode muss verfügbar gemacht werden. Marken & Namensnennung
Die Namen picoZ80, pico6502 und engineers@work sind Marken von Philip Smart. Sie dürfen diese Namen nicht verwenden, um abgeleitete Produkte zu bewerben, ohne schriftliche Genehmigung. Sie dürfen Copyright-Hinweise, Autorennennung oder Boot-/Startbildschirm-Credits nicht entfernen oder ändern. Das Umbenennen dieses Projekts und die Darstellung als eigene Arbeit ist ausdrücklich untersagt. Siehe die Datei
Wenn Sie ein Hersteller oder Distributor sind, der an der kommerziellen Produktion von picoZ80- oder pico6502-Platinen interessiert ist, kontaktieren Sie bitte: info@eaw.app. Persönliche, bildungsbezogene und Hobbyisten-/Vereinsnutzung ist unter den oben genannten Open-Source-Lizenzen stets gestattet. Die vollständigen Lizenztexte sind im Repository als
Alle Hardware-Designs (KiCad-Schaltpläne, PCB-Layouts, Gerber-Fertigungsdateien, Stücklisten) sind unter der Creative Commons Namensnennung-Nicht kommerziell-Weitergabe unter gleichen Bedingungen 4.0 International Lizenz lizenziert. Sie dürfen die Designs nur für nicht-kommerzielle Zwecke teilen und anpassen, vorausgesetzt, Sie geben angemessene Anerkennung und verteilen alle Modifikationen unter derselben Lizenz. Kommerzielle Herstellung oder Verkauf erfordert eine separate Lizenz — bitte kontaktieren Sie info@eaw.app. Firmware & Software — GNU GPL v3
Die Firmware und der Software-Quellcode sind freie Software unter der GNU General Public License v3. Sie dürfen den Code unter den Bedingungen der GPL v3 weiterverteilen und modifizieren. Alle verteilten Modifikationen müssen ebenfalls unter GPL v3 lizenziert sein und der Quellcode muss verfügbar gemacht werden. Marken & Namensnennung
Die Namen picoZ80, pico6502 und engineers@work sind Marken von Philip Smart. Sie dürfen diese Namen nicht verwenden, um abgeleitete Produkte zu bewerben, ohne schriftliche Genehmigung. Sie dürfen Copyright-Hinweise, Autorennennung oder Boot-/Startbildschirm-Credits nicht entfernen oder ändern. Das Umbenennen dieses Projekts und die Darstellung als eigene Arbeit ist ausdrücklich untersagt. Siehe die Datei
NOTICE im Repository für vollständige Details.
Kommerzielle LizenzierungWenn Sie ein Hersteller oder Distributor sind, der an der kommerziellen Produktion von picoZ80- oder pico6502-Platinen interessiert ist, kontaktieren Sie bitte: info@eaw.app. Persönliche, bildungsbezogene und Hobbyisten-/Vereinsnutzung ist unter den oben genannten Open-Source-Lizenzen stets gestattet. Die vollständigen Lizenztexte sind im Repository als
LICENSE, LICENSE-HARDWARE.txt und LICENSE-SOFTWARE.txt enthalten.
Hinweis zur Funkregulierung
Dieses Gerät enthält ein ESP32-S3-PICO-1 Funkmodul, das im 2,4 GHz ISM-Band senden kann, wodurch es bei aktiviertem WiFi ein absichtlicher Strahler im Sinne der weltweiten Hochfrequenzvorschriften ist (einschließlich FCC Part 15 Subpart C in den Vereinigten Staaten und der Funkanlagenrichtlinie 2014/53/EU in der Europäischen Union).
Nur-NCM-Standard für nicht zertifizierte Platinen
Da die picoZ80 als fertige Baugruppe keine FCC- oder RED-Zertifizierung durchlaufen hat, müssen Platinen mit dem WiFi-Antennen-Anpassungsnetzwerk unbestückt und der ESP32-Firmware im Nur-NCM-Modus (
Es liegt in der alleinigen Verantwortung des Bauherrn sicherzustellen, dass jedes aus diesen Designs konstruierte Gerät allen geltenden Hochfrequenzvorschriften in seiner Rechtsordnung entspricht. Der Autor stellt diese Designs für den persönlichen, bildungsbezogenen und Hobbygebrauch zur Verfügung und macht keine Zusicherung, dass ein aus ihnen gebautes Gerät die regulatorischen Anforderungen für eine kommerzielle Verbreitung erfüllt.
Da die picoZ80 als fertige Baugruppe keine FCC- oder RED-Zertifizierung durchlaufen hat, müssen Platinen mit dem WiFi-Antennen-Anpassungsnetzwerk unbestückt und der ESP32-Firmware im Nur-NCM-Modus (
sdkconfig.mode_ncm_only) ausgeliefert werden. In dieser Konfiguration wird keine Hochfrequenzenergie abgestrahlt und die Platine unterliegt nicht den Vorschriften für absichtliche Strahler. Die vollständige Web-Oberfläche bleibt über USB unter http://192.168.7.1 zugänglich. Siehe den Abschnitt Netzwerk — FCC-/RED-Regulierungshinweis oben für weitere Details.
Obwohl das ESP32-S3-PICO-1-Modul selbst bereits bestehende behördliche Zertifizierungen besitzt (FCC, CE und andere), erstrecken sich diese Modul-Level-Zertifizierungen nicht automatisch auf ein fertiges Produkt, das das Modul integriert. Die Ausnahme für vorzertifizierte Module erlaubt es einzelnen Hobbyisten, eine begrenzte Anzahl von Geräten für den persönlichen, experimentellen oder Bildungsgebrauch zu bauen, ohne eine separate Geräteautorisierung zu erhalten.
Wichtige Einschränkungen- Zusammengebaute Geräte mit aktiviertem WiFi dürfen nicht verkauft, zum Verkauf angeboten, verschenkt oder anderweitig an Dritte verteilt werden, es sei denn, das fertige Produkt wurde unabhängig getestet und hat seine eigene Geräteautorisierung (z.B. FCC ID, CE-Kennzeichnung mit Bewertung durch eine benannte Stelle) in der jeweiligen Rechtsordnung erhalten.
- Platinen, die an andere versandt oder verteilt werden, müssen die Nur-NCM-Firmware-Konfiguration mit unbestücktem WiFi-Antennen-Anpassungsnetzwerk verwenden.
- Der Bau dieses Projekts für den persönlichen Gebrauch in begrenzter Stückzahl mit aktiviertem WiFi ist im Allgemeinen unter den Hobbyisten- und Experimentalnutzungsbestimmungen gestattet (z.B. FCC § 15.23), vorausgesetzt, das Gerät verursacht keine schädlichen Interferenzen.
- Die regulatorischen Anforderungen variieren je nach Land. Bauherren außerhalb der Vereinigten Staaten sollten ihre nationale Funkfrequenzbehörde bezüglich der geltenden Regeln konsultieren.
Es liegt in der alleinigen Verantwortung des Bauherrn sicherzustellen, dass jedes aus diesen Designs konstruierte Gerät allen geltenden Hochfrequenzvorschriften in seiner Rechtsordnung entspricht. Der Autor stellt diese Designs für den persönlichen, bildungsbezogenen und Hobbygebrauch zur Verfügung und macht keine Zusicherung, dass ein aus ihnen gebautes Gerät die regulatorischen Anforderungen für eine kommerzielle Verbreitung erfüllt.