pico6502

Übersicht

Der pico6502 ist das Gegenstück zum picoZ80 für die 6502-Familie. Er verwendet die identische Board-Hardware — einen RP2350B-Mikrocontroller, 8MB PSRAM, 16MB Flash und einen ESP32-Co-Prozessor — zielt jedoch auf den MOS 6502 DIP-40-Sockel statt auf den Z80 ab. In einen beliebigen 6502-basierten Computer eingebaut, ersetzt der pico6502 die physische CPU und übernimmt über die PIO-Zustandsmaschinen des RP2350 die vollständige, zyklusgenaue Kontrolle über die Adress-, Daten- und Steuerbusse des 6502.

Wie der picoZ80 wird der pico6502 vollständig über JSON konfiguriert. Eine config.json-Datei auf der SD-Karte definiert die Speicherbelegung, die ROM-Images und die Treiberbindungen. Für die Anpassung an einen anderen 6502-basierten Host oder die Änderung des Speicherlayouts ist keine Neukompilierung erforderlich. Die gesamte Verwaltung erfolgt über eine browserbasierte Oberfläche, die vom integrierten ESP32 bereitgestellt wird.

Drop-in-6502-Ersatz
- passt in jeden 6502 DIP-40-Sockel. Verifiziert in einem BBC Model B und einem Apple-I-Nachbau: Der Host sieht reines 6502-Busverhalten — Ein-Zyklus-Schreibzugriffe, Adresswechsel innerhalb des 110–225 ns-Fensters des echten Chips, Lesezugriffe abgetastet bei der fallenden PHI2-Flanke, pegelgesteuertes /IRQ, entprelltes /RES.

PIO-Bus-Engine mit gepipelinetem spekulativem Fetch
- acht PIO-Zustandsmaschinen des RP2350 treffen jede Timing-Entscheidung (PHI1/PHI2-Erzeugung, Adressleiter, an R/W gekoppelte Schreibdaten, ein transparentes Lese-Latch, IRQ/NMI/SO-Monitore). Mit einer Maschinen-Persona, die ihr I/O-Fenster und ihr Paging-Register deklariert, streamt die Engine Befehlsbytes mit einem Host-Zyklus pro Byte, spiegelt und verifiziert jedes gelieferte Byte und führt die Software des BBC Model B in vollem Tempo aus, während der Bus byteidentisch zu einem echten 6502 bleibt. Ein „Vanilla“-Host ohne deklarierte Speicherbelegung läuft ebenfalls, aber konservativ.

NMOS- und CMOS-Kerne
- alle 151 offiziellen Befehle plus jeder undokumentierte NMOS-Opcode (einschließlich der JAM-Gruppe), mit einem über cputype gewählten 65C02/65C12-Overlay: (zp)-Adressierung, PHX/PHY/PLX/PLY, STZ, TSB/TRB, BRA, INC/DEC A, das korrigierte JMP (abs) und die CMOS-NOP-Spalten.

Großer gebankter Speicherbereich
- 8MB PSRAM als 64 Bänke × 64KB, konfigurierbar in 512-Byte-Blöcken als RAM-, ROM-, PHYSICAL- oder FUNC-Typen.

Framework für virtuelle Geräte
- jeder Speicherbereich kann durch eine C-Handler-Funktion hinterlegt werden, was virtualisierte Peripheriegeräte wie 6522 VIA, 6845 CRTC oder benutzerdefinierte I/O ermöglicht. Virtuelle Geräte können eine virtuelle /IRQ-Leitung auslösen, die der Kern zusammen mit dem physischen Pin abtastet.

BBC-Model-B-Persona
- eine Persona mit physischem Passthrough, die das Maschinenwissen des Model B mitbringt (I/O-Fenster, Shadow-Write-Fenster, ROMSEL-Paging, Burst-Tiefe). Fügt 16 virtuelle Sideways-ROM/RAM-Sockel hinzu (PSRAM-gestützt, folgen ROMSEL — MMFS oder ein Sprach-ROM von SD laden, ohne physischen Sockel), einen virtuellen OS-Sockel, ein 16K-RAM-Overlay für Model-A-Hosts, ein BBC-Master-Speichermodell (LYNNE/HAZEL/ANDY, virtuelles ACCCON) sowie CMOS-/Sideways-RAM-Persistenz auf SD oder Flash.

Virtuelles UEF-Kassettendeck
- das CMT-UEF-Interface virtualisiert den 6850 ACIA und die Serial ULA des BBC und spielt (gzip-komprimierte) UEF-Bänder mit echtem 1200/300-Baud-Timing über die virtuelle Interrupt-Leitung ab; SAVE zeichnet den Sendestrom in eine neue UEF-Datei auf der SD-Karte auf. Ein Bandkarussell mit sechs Slots wird über die Web-GUI oder den Shell-Befehl bbc tape verwaltet.

Virtueller Floppy-Controller — Intel 8271 oder WD1770, DFS und ADFS
- das BBC-FDC-Interface bietet die Wahl zwischen zwei Controllern, jeder ein hostunabhängiges Chipmodell nach Datenblatt: der native Intel 8271 des Model B bei $FE80 (Acorn DFS 0.90/1.20, Watford- und Solidisk-8271-ROMs) oder ein WD1770 hinter einem Laufwerkssteuer-Latch, wie ihn das Acorn Model B 1770 Upgrade Board, das Watford Electronics 1770 Board oder der integrierte Controller des BBC Master 128 verwenden — Double-Density- und ADFS-fähig (Acorn DFS 2.2x, DDFS, ADFS 1.3x/1.5x). Zwei doppelseitige Laufwerke werden von der SD-Karte bedient: .ssd/.dsd-DFS-Images, Double-Density-DDFS-Images, ADFS-.adf- (S/M/L, Seite nach Seite) und .adl-Images (L, interleaved), eine Diskette aus einem MMB-Bundle (mmb/BEEB.MMB:3) oder zwei einseitige Images, die als die beiden Seiten einer doppelseitigen Diskette gepaart werden — DFS-Laufwerke 0/2 und 1/3, genau so, wie Archive wie ACORN3_A / ACORN3_B ausgeliefert werden. Die Image-Art wird pro Slot festgelegt oder aus Erweiterung und Größe abgeleitet. Schreibzugriffe gehen über einen Write-Back-Blockcache zurück; Disketten werden live über das Floppy-Menü des Dashboards gewechselt.

Virtuelle MMFS-Karte
- das BBC-MMC-Interface stellt eine SD-Karte hinter dem User VIA für das unveränderte MMFS-ROM bereit (User-Port, Non-Turbo-Build): Die MMB auf der Karte des pico6502 wird als BEEB.MMB auf einer FAT16-Fassade präsentiert, sodass Hunderte Disketten ohne jegliche Hardware am User-Port verfügbar sind. Lädt man das MMFS-ROM selbst aus einem virtuellen Sideways-Sockel, ist das gesamte Dateisystem in sich geschlossen.

Virtuelles Econet über IP
- das BBC-NET-Interface ist ein virtuelles Econet-Modul — der 68B54 ADLC bei $FEA0 und die Stationsnummern-Links bei $FE18, genau so, wie die NFS-3.60-/ANFS-4.x-ROMs sie programmieren — übertragen über die WiFi- oder USB-Netzwerkverbindung des ESP32 als AUN (Acorn Universal Networking, Econet-Pakete in UDP auf Port 32768), das Protokoll, das BeebEm und RISC OS verwenden. Der vierstufige Econet-Handshake wird Frame für Frame gegen das ROM ausgeführt und wie bei einer Bridge nach AUN übersetzt, sodass jeder AUN-Dateiserver den BBC bedienen kann: Zwei bewährte Open-Source-Daemons, aund und der Dateiserver der PiEconetBridge, sind in tools/econet/ mit einem Build-Skript und einem Ein-Befehl-Dateiserver gebündelt. Verifiziert mit ANFS 4.25 auf einem Board im Master-Modus sowie mit NFS 3.60 und ANFS 4.18 im Simulator.

Laden von ROM-Images
- ROM-Images für den Host-Rechner (BIOS, Monitor, Sprach-ROMs) werden auf der SD-Karte gespeichert und beim Booten in das PSRAM geladen; die Konfiguration selbst wird minifiziert und genau wie beim picoZ80 im Flash persistiert, sodass das Board ohne Abhängigkeit von der ESP32-Verbindung bootet.

Integrierter Assembler und Disassembler
- ein vollständiger 6502-Disassembler und Einzeilen-Assembler, in die Debug-Shell eingebaut, deckt alle 13 Adressierungsarten und die undokumentierten Opcodes (mit Präfix *) ab, verifiziert über 2048 Round-Trip-Fälle.

ICE-Debug-Shell
- die CPU-neutrale Debug-Shell, die mit dem picoZ80 geteilt wird: 61 Befehle auf dem 6502 (62 im BBC6502-Build), darunter Bring-up-Diagnosen (busdiag, busprobe, busverify, bustest, busstate), Live-Stellschrauben der Bus-Engine (buspipe, writestrobes, iopark, readsettle, readphase), eine Geschwindigkeitsanzeige (cpustat, cpuprof) und der Persona-Befehl bbc.

Host-Simulator
- pico6502sim führt die echte Firmware — RP2350- und ESP32-Hälfte — nativ auf einem PC aus, jetzt mit einem synthetischen BBC-Model-B-Host (System-VIA, Tastaturmatrix, MODE 7 auf einem Terminal gerendert) neben dem Apple I. Neue Treiber wie das UEF-Bandlaufwerk werden hier erprobt, bevor sie die Hardware berühren.

WiFi- und Web-Verwaltung
- dieselbe achtseitige Bootstrap-Weboberfläche wie beim picoZ80 — Dashboard, strukturierte Konfigurations-GUI, Roh-Konfigurationseditor, Dateimanager, Persona-Auswahl, OTA-Firmware-Updates, WiFi-Manager. Die Oberfläche ist CPU-bewusst: Mit laufender pico6502-Firmware zeigt sie nur 6502-Personas und -Treiber, blendet die Z80-I/O- und Medienmenüs aus und ergänzt Takt/Spannung pro Partition, ein Bus-Engine-Tuning-Panel, die BBC-Maschinenoptionen und die Sideways-Sockel-Tabelle.

Duale Firmware-Partitionen
- zwei 5MB-Firmware-Slots mit OTA-Update-Unterstützung und Bootloader-verwalteter Partitionsumschaltung.

USB-Firmware-Update
- der Bootloader stellt eine USB-Brücke für das initiale Flashen ohne Hardware-Debugger bereit.

X (Twitter) Projektvorschau — picoZ80/pico6502 in Aktion

Hardware

Die pico6502-Platine ist ein kompaktes 52mm × 19mm großes Board, das dasselbe Grunddesign wie der picoZ80 teilt, aber anstelle eines Z80-Interfaces ein 6502-spezifisches Bus-Interface trägt. Vier Schaltplanblätter decken den RP2350B-Prozessor, den ESP32-Co-Prozessor, das 6502-Bus-Interface und die Stromversorgung ab. Revision v2.2 (unten neben einem originalen 6502 und eingebaut in einen Apple-1-Nachbau zu sehen) bestätigte das mechanische Format und brachte beide Prozessoren zum Laufen, lag beim Bus- und Takt-Timing jedoch daneben; das v2.3-Redesign antwortet darauf mit einem vollständig gepufferten Interface — 74AHCT244-Adress-/Steuerpuffer, ein 74AHCT245-Datenpuffer und getrennte Hin- und Rücklaufpfade für den Takt, sodass ein defekter Puffer von einem fehlenden Takt unterschieden werden kann. v2.3a ist das aktuelle Board und dasjenige, das im BBC Model B und Apple I erprobt wurde; sein Schaltplan ist pico6502_v2_3a.pdf im Repository, und es ist das unten fotografierte Board, Bestückungsseite und Unterseite. Der im picoZ80 v2.5 vorhandene USB-Hub ist auf der abgebildeten Revision v2.2 nicht bestückt. Die gesamte Logik arbeitet mit 3,3V, wobei das gepufferte Interface die 5V-Signalpegel des 6502 treibt.

Hauptkomponenten

RP2350B (Cortex-M33 Dual-Core)
- Hauptprozessor, je Persona übertaktet: Die BBC-Model-B-Persona betreibt ihn mit 340MHz (die Spannung ist boardabhängig — 1,20V auf der Referenzeinheit; 330MHz benötigten auf einem anderen Board ~1,35V), die Vanilla- und Apple-I-Personas mit 150MHz. Core 1 führt die 6502-Emulations-Hauptschleife aus; Core 0 übernimmt Datei-I/O, USB und ESP32-Relay. 512KB On-Chip-SRAM.

16MB SPI Flash
- gleiches Layout wie beim picoZ80: Bootloader, zwei 5MB-Anwendungsslots, zwei Konfigurationsslots, allgemeine Konfiguration und Partitionstabelle.

8MB PSRAM (SPI)
- 64 Bänke × 64KB gebankter Adressraum für den emulierten 6502. Speicherblock-Zeiger-Arrays und I/O-Funktionszeiger-Arrays befinden sich im PSRAM oberhalb des RAM/ROM-Bereichs.

ESP32-Co-Prozessor
- WiFi, SD-Karte, Webserver. Kommuniziert mit dem RP2350 über 60MHz FSPI (binäre IPC-Frames mit CRC32 und Opcode-/Sequenzprüfung) und eine 460,8kBaud-UART-Brücke.

SD-Kartenslot
- FAT32, verwaltet vom ESP32. Speichert config.json, ROM-Images und Disk-Images.

USB-Hub
- integrierter USB-Hub für Host-Konnektivität und Firmware-Update-Brücke.

3,3V-Stromversorgung
- Abwärtswandler von den 5V am VCC-Pin des 6502 DIP-40.

Board-Design (KiCad)

Die pico6502-Hardware wird in KiCad entworfen. Schaltplan- und PCB-Layout-Dateien für die Revisionen v2.1 und v2.2 liegen im Projekt-Repository unter kicad/PICO6502/; die aktuelle Revision ist v2.3a (pico6502_v2_3a.pdf), die das oben beschriebene gepufferte Bus-Interface hinzufügt und das Board ist, mit dem alle Hardware-Ergebnisse auf dieser Seite erzielt wurden.

Die vier Schaltplanblätter sind:

Blatt 1 — RP2350B-Prozessor

RP2350B-QFN-80-GPIO-Zuordnungen für den 6502-Bus, 16MB Flash, 8MB PSRAM und die ESP32-Kommunikation. Der 6502-Bus benötigt A0–A15, D0–D7, PHI0/PHI1/PHI2, RNW, SYNC, IRQ, NMI, RDY und RESET — und belegt damit die Mehrheit der 48 GPIO-Pins des RP2350B.

pico6502 Schematic Sheet 1 — RP2350B Processor

Blatt 2 — ESP32-Co-Prozessor

ESP32-Modul, SD-Karten-Interface, Antenne und Inter-Prozessor-Kommunikation (FSPI + UART). Funktional identisch mit dem picoZ80-Design.

pico6502 Schematic Sheet 2 — ESP32 Co-processor

Blatt 3 — 6502-Bus-Interface

Die DIP-40-Sockelanschlüsse und das Bus-Interface. Anders als der Z80 hat der 6502 keinen separaten I/O-Adressraum — alle Peripheriegeräte sind speicherabgebildet. Ab v2.3 laufen die Sockelsignale über ein vollständig gepuffertes Interface: 74AHCT244-Puffer treiben die Adress- und Steuerleitungen nach außen, ein 74AHCT245 übernimmt den bidirektionalen Datenbus, und die beiden Taktphasen haben getrennte Hin- und Rücklaufpfade, sodass die Firmware vergleichen kann, was sie treibt und was tatsächlich am Sockel anliegt (die Diagnose busdiag clk — genau die Unterscheidung, die das ungepufferte v2.2-Board nicht treffen konnte). Der Tri-State der Puffer folgt dem DBE-Pin des Sockels, verknüpft mit einem vom ESP32 getriebenen DBE_OVR-Override (~EN = NOR(DBE, DBE_OVR)), sodass Hosts, die DBE nicht treiben, unverändert funktionieren.

pico6502 Schematic Sheet 3 — 6502 Bus Interface

Blatt 4 — Stromversorgung

TLV62590BV-Synchron-Abwärtswandler von 5V auf 3,3V mit Ein-/Ausgangsfilterung. Versorgt sich vom VCC-Pin des 6502-DIP-40-Sockels.

pico6502 Schematic Sheet 4 — Power Supply

KiCad-Quelldateien: kicad/PICO6502/PICO6502_Schematic.pdf (Schaltplan-PDF) und kicad/PICO6502/ (vollständiges KiCad-Projekt).

👀 Interaktive Stückliste — pico6502 v2.2 (Viewer für die PCB-Bauteilplatzierung)

pico6502 v2.3a — Bestückungsseite: RP2350B, ESP32-S3-Modul, USB-C und der Debug-Header

pico6502 v2.3a — Unterseite: SD-Kartenslot, Buspuffer, Flash und PSRAM sowie die DIP-40-Pins

pico6502 v2.2 neben einem originalen MOS-6502-Chip — gleicher DIP-40-Footprint

pico6502 eingebaut in einen RC6502 Apple 1 Replica

Architektur

Dual-Core-Design

Die Kernzuordnung des RP2350B entspricht der des picoZ80:

Core 0 — USB-Brücke, Koordination der Firmware-Updates, Datei-I/O-Relay zum ESP32, Dispatch der ESP32-UART-Befehle, Partitionsverwaltung.

Core 1 — Die 6502-Emulations-Hauptschleife. Bedient die PIO-FIFOs zur Verarbeitung der 6502-Bustransaktionen, löst jede Adresse gegen die Speicherbelegung auf und verteilt an PSRAM, PHYSICAL-Passthrough oder FUNC-Handler virtueller Geräte. Die innere Schleife läuft für minimale Latenz aus dem RP2350-SRAM.

Die Inter-Core-Kommunikation verwendet dieselbe queue_t-Nachrichtenübermittlung wie der picoZ80 und transportiert Nachrichten für Floppy-/Disk-Image-Wechsel, Konfigurations-Reloads, Lese-/Schreibzugriffe auf Dateien und Abfragen der Firmware-Version.

PIO-Bus-Interface

Das 6502-Bus-Interface ist in M6502.pio implementiert und wird aus M6502CPU.c angesteuert. Das Designprinzip, das sich während des BBC-Model-B-Bring-ups herausgebildet hat, lautet: Die PIO trifft jede Timing-Entscheidung — in einen Buszyklus ist kein C-seitiges Timing involviert. Acht Zustandsmaschinen über die drei PIO-Blöcke werden geladen:

PIO	SM	Programm	Funktion
PIO 0	0	`m6502_addr`	Die Adress-Engine (v3, „ladder + gated + burst unified“). Treibt A0–A15 und besitzt R/W und SYNC. Jedes FIFO-Wort ist `{instr:16 \| ~addr:16}` — die obere Hälfte wird mit `out exec` ausgeführt, sodass ein Wort „Lesen mit Burst von N“, „Schreiben“ oder „gesteuerter Einzelzyklus“ bedeuten kann.
PIO 0	2	`m6502_latch`	Transparentes Eingangs-Latch (v4): tastet D0–D7 kontinuierlich ab, solange PHI2 high ist, und liefert den letzten Zustand vor der fallenden Flanke — den Zeitpunkt, an dem das Videosystem des BBC den RAM-Bus übernimmt.
PIO 1	0	`m6502_cycle`	Exec-getriebener Zyklussequenzer für den gesteuerten (serialisierten) Pfad — I/O-Zugriffe, langsame Blöcke und RDY-Wartezustände.
PIO 1	1	`m6502_so`	Überwacht den SO-Pin (PIO IRQ 6).
PIO 1	2	`m6502_irq`	Spiegelt /IRQ in PIO IRQ 5; der Kern tastet es pro Befehl mit Pegelsemantik ab, wie echtes Silizium.
PIO 1	3	`m6502_nmi`	Spiegelt /NMI in PIO IRQ 4; Core 1 erkennt die Flanke und übernimmt beim Reset den vorherigen Zustand von der realen Leitung, sodass ein bereits anliegender Low-Pegel keine Scheinflanke ist.
PIO 2	0	`m6502_clock_6502` / `m6502_clock_6512`	6502-Modus: erzeugt PHI1/PHI2 aus dem PHI0 des Hosts. 6512-Modus: geparkt, der Host liefert beide Phasen.
PIO 2	1	`m6502_data`	Treiber für Schreibdaten, rein an R/W gekoppelt: treibt D0–D7, solange R/W low ist, und gibt frei, wenn es wieder high wird, sodass ein Schreibzugriff ein Zyklus mit einem Strobe ist, wie auf einem echten 6502.

Jede Bus-Zustandsmaschine synchronisiert sich auf CLK2_IN — die tatsächlich am Sockel anliegende PHI2-Phase, zurückgelesen über den Rücklaufpfad des Puffers — sodass dasselbe Programm den 6502 und den 6512 bedient. Die Programme m6502_fetch, m6502_read und m6502_write verbleiben als Referenzsequenzen im Quellcode; ihre Befehle sind das, was die Zyklus-SM als Exec-Wörter ausführt. Schreibzugriffe halten die Daten für die tHW des echten Chips (~44 ns bei 340 MHz), und die Adress-Engine wechselt die Adresse erst nach einer echten fallenden PHI2-Flanke gefolgt von der tADS-Setup-Zeit, wobei sie ihr FIFO auf einer „Leiter“ mit vier Sprossen abfragt, sodass der ungünstigste Treibzeitpunkt bei ~206–215 ns liegt — innerhalb des Adresswechselfensters eines echten 6502. Die vollständige Beschreibung finden Sie im Technischen Handbuch.

Speichermodell

Das 6502-Speichermodell ist strukturell identisch mit dem Z80-Modell, jedoch ohne separaten I/O-Adressraum — da der 6502 kein IORQ-Äquivalent hat, erscheinen alle Peripherieregister in der 64KB-Speicherbelegung. Es gilt dieselbe dreistufige Architektur:

Stufe 1 — RP2350-SRAM: Blockzeiger-Array mit 128 Einträgen für O(1)-Dispatch pro 512-Byte-Block.
Stufe 2 — PSRAM (8MB): 64 Bänke × 64KB RAM/ROM-Images und Funktionszeiger-Arrays.
Stufe 3 — Flash (16MB): Firmware, ROM-Images, minifiziertes Konfigurations-JSON.

Für die 6502-Speicherbelegung verfügbare Speicherblocktypen:

Typ	Beschreibung
`PHYSICAL`	Passthrough zur realen Host-Hardware.
`PHYSICAL_VRAM`	Host-Video-RAM mit Wartezuständen.
`RAM`	Lesen/Schreiben — hinterlegt durch eine PSRAM-Bank.
`ROM`	Nur Lesen — hinterlegt durch eine PSRAM-Bank.
`PHYSICALHW`	Passthrough-Bereich, der als Host-Hardware deklariert ist (ein I/O-Fenster). Die Bus-Engine spekuliert niemals hinein oder darüber hinweg, und das konfigurierbare Adress-Parkziel wird konfigurationsgesteuert, sobald ein solcher Bereich deklariert ist.
`VRAM`	PSRAM-gestützter Video-RAM-Spiegel mit Wartezuständen.
`FUNC`	Virtuelles Gerät — C-Handler wird bei jedem Zugriff aufgerufen. Wird für die gesamte Peripherie-Emulation verwendet, da der 6502 keinen I/O-Adressraum hat.
`PTR`	Umleitung pro Byte.

Flash-Speicherlayout

Identisch mit dem picoZ80-Layout:

Partition	Adressbereich	Größe	Inhalt
Bootloader	`0x10000000–0x1001FFFF`	128KB	USB-Brücke, Firmware-Update, Partitionsauswahl
App Slot 1	`0x10020000–0x1051FFFF`	5MB	Haupt-6502-Firmware (Partition 1)
App Slot 2	`0x10520000–0x10A1FFFF`	5MB	Haupt-6502-Firmware (Partition 2)
App Config 1	`0x10A20000–0x10C9FFFF`	2,5MB	ROM-Images + minifiziertes Konfigurations-JSON (Slot 1)
App Config 2	`0x10CA0000–0x10F1FFFF`	2,5MB	ROM-Images + minifiziertes Konfigurations-JSON (Slot 2)
General Config	`0x10F20000–0x10FFEFFF`	892KB	Kerneinstellungen, Scratch-Bereich
Partition Table	`0x10FFF000–0x11000000`	4KB	Aktiver Slot, Prüfsummen, Metadaten

Seit September 2026 speichert die 6502-Firmware ihre Konfiguration genau wie die Z80-Modelle im Flash: Das Anwenden einer Konfiguration (Web-GUI Apply / Reload) liest config.json von der SD-Karte, minifiziert sie, schreibt den Blob zusammen mit der geparsten Maschinendefinition und dem Kerntakt/der Kernspannung in den App-Config-Bereich der Partition und startet neu — der nächste Boot liest alles aus dem Flash, ohne Abhängigkeit vom ESP32. Die Option "persist": "flash" der BBC-B-Persona reserviert zusätzlich einen nichtflüchtigen Bereich (ein Meta-Sektor plus 16 × 16K Sideways-RAM-Slots, ~260KB pro Partition) am Ende des General-Config-Bereichs für ihr virtuelles CMOS und Sideways-RAM.

Bus-Engine und Performance

Der emulierte 6502 ist nur so schnell, wie die Bus-Engine seinen Befehlsstrom holen kann. Das serialisierte Design, mit dem der BBC zuerst zum Laufen gebracht wurde — ein C-seitiger Round-Trip pro Busoperation — war korrekt, aber langsam, und eine Geschwindigkeitskampagne im September 2026 (Schritt für Schritt in PIPELINE_REDESIGN.md dokumentiert) ersetzte es durch eine gepipelinete Engine. Die Techniken, in der Reihenfolge, in der sie bewiesen wurden:

Adressleiter und 1-Zyklus-Regime
- die Adress-SM fragt ihr FIFO nach jeder fallenden PHI2-Flanke auf festen Sprossen ab, sodass ein rechtzeitig eingereihtes Wort innerhalb des Adresswechselfensters des echten Chips getrieben wird und eine Operation in einem einzigen Host-Zyklus ohne C-Timing in der Schleife abgeschlossen wird.

Burst-Engine
- ein Lesewort kann bis zu 6 aufeinanderfolgende Adressen anfordern; die SM zählt die Adresse selbst weiter (die PIO hat keinen Addierer, daher zählt sie eine invertierte Adresse herunter) und Befehlsbytes strömen mit einem Zyklus pro Byte. Bytes, die gerettet werden, wenn eine Busoperation den Strom unterbricht, werden in einem Harvest-Puffer aufbewahrt und späteren Fetches ohne jede Busoperation geliefert.

Shadow und Serve
- ein 64KB-Write-Through-Shadow mit einer Gültigkeits-Bitmap füllt sich träge aus dem Busstrom (ROM eingeschlossen, das I/O-Fenster niemals). Jedes vom Bus abgeholte Byte wird gegen den Shadow verifiziert, und der Mismatch-Zähler muss bei null bleiben — jeder 256-Byte-Block, der jemals abweicht, wird auf den langsamen gesteuerten Pfad in Quarantäne gestellt. Nach dem Nachweis (1,38 Milliarden gelieferte Bytes bei null Abweichungen) liefert Serve shadow-gültige Bytes sofort an den Kern, während der echte Buszyklus noch läuft, sodass der Bus byteidentisch zu einem echten 6502 bleibt, während der Kern nicht mehr auf ihn warten muss.

Native Schreibzugriffe und verschmolzene Fetches
- Schreibzugriffe werden zu Fire-and-Forget-Leiterwörtern mit einer Write-Pending-Sperre und FIFO-Rückstau; Opcode- und Operanden-Fetches sind direkte Inline-Aufrufe unter partieller Link-Time-Optimierung.

I/O-Chase
- auf jeden Zugriff innerhalb des deklarierten I/O-Fensters folgt ein Park-Lesezugriff ohne Erfassung auf den Reset-Vektor, sodass ein Register mit Nebenwirkungen (die FIFOs der Tube ULA im Fall des PiCoPro) niemals durch eine über Leerlaufzyklen gehaltene Adresse erneut dekodiert wird.

Alles oben Genannte setzt voraus, dass die Persona ein I/O-Fenster deklariert — ohne ein solches bleibt die Engine konservativ. Genau das liefert der BBC-Model-B-Treiber, und deshalb verwandelt seine Auswahl die Geschwindigkeit der Maschine — Elite, Aviator, Galaxians, MMFS und lange Dauerläufe laufen alle sauber, und der Shell-Befehl cpustat meldet die emulierte Rate gegenüber dem gemessenen Host-Takt, sodass der Fortschritt bei der Weiterentwicklung der Engine verfolgt werden kann. Die Stellschrauben — Burst-Tiefe, I/O- und Shadow-Write-Fenster, Paging-Register, Serve, Pipeline — sind auch pro Treiber über das Panel Bus Engine Tuning der Web-GUI und den Shell-Befehl buspipe verfügbar, sodass eine andere Maschine ohne Firmware-Änderung abgestimmt werden kann.

Maschinen-Personas

Wie beim picoZ80 ist eine Persona eine benannte Konfiguration, die Speicherbelegung, ROMs und Treiber für einen bestimmten Host-Rechner auswählt und pro Firmware-Partition über die Weboberfläche gewählt wird. Die Persona-Seite ist CPU-bewusst: Mit laufender pico6502-Firmware bietet sie nur die 6502-Personas an. Die Persona-Dateien paaren eine Maschine pro Partition (config_<Partition1>_<Partition2>.json), und drei Maschinen werden mitgeliefert:

Basic6502 — „Vanilla 6502“
- der Open6502-Treiber ohne jegliche Virtualisierung; jeder Buszyklus wird bei 150MHz an den Host-Rechner durchgereicht. Dies ist die Persona, mit der ein neues Board in Betrieb genommen werden sollte.

Apple-I — „Apple I / Nachbau“
- der Apple-I-/RC6502-Nachbau-Host auf dem Open6502-Treiber. Sein 6821 PIA, RAM und Monitor-ROM befinden sich alle auf dem Host, sodass nichts virtualisiert wird; der Woz-Monitor und BASIC laufen auf dem v2.3a-Board.

BBC-B — „BBC Model B“
- der BBC-B-Treiber (src/drivers/Acorn/BBCModelB.c, im BBC6502-Firmware-Build): eine Persona mit physischem Passthrough, die das Maschinenwissen des Model B beisteuert — I/O-Fenster $FC00–$FEFF, Shadow-Write-Fenster $0000–$7FFF, ROMSEL bei $FE30 (Maske $FFF0, teilweise dekodiert) mit Paging von $8000–$BFFF, Burst-Tiefe 6 — als Standardwerte, die das JSON überschreiben kann. Betreibt den RP2350 mit 340MHz. Zusätzlich zum Passthrough bietet sie 16 virtuelle Sideways-ROM/RAM-Sockel, einen virtuellen OS-Sockel, das Model-A-RAM-Overlay, den BBC-Master-Modus (der den CMOS-Kern erzwingt, da MOS 3.x 65C12-Code ist), CMOS-/Sideways-RAM-Persistenz und vier bindbare Interfaces: das CMT-UEF-Bandlaufwerk, den virtuellen BBC-FDC-Floppy-Controller (Intel 8271 oder WD1770 — DFS, DDFS und ADFS), die virtuelle BBC-MMC-MMFS-Karte und das virtuelle BBC-NET-Econet-Modul (AUN über IP).

Der Open6502-Treiber lädt alle konfigurierten ROM-Images in ihre bank:addr-Abschnitte, markiert ROM-Blöcke der Bank 0 als schreibgeschützt und belässt den Adressraum ansonsten genau so, wie ihn das memory-Array der Persona definiert. Maschinenspezifische Treiber werden über dasselbe Treiber-Framework wie die Z80-Maschinen eingebunden; der 65C12, das Shadow-RAM und das Paging des BBC Master werden heute als Modus des BBC-B-Treibers behandelt und würden als Geschwistertreiber zu einem eigenen Treiber werden.

Build-Anleitung

Der pico6502 verwendet dasselbe Build-System und dieselbe Verzeichnisstruktur wie der picoZ80. Bitte folgen Sie der picoZ80-Build-Anleitung für die vollständige Einrichtungsprozedur — Anlegen des Stammverzeichnisses, Setzen von PICO_PATH, Ausführen von get_and_build_sdk.sh und Konfigurieren des Docker-Alias für ESP-IDF. Die pico6502-spezifischen Unterschiede sind unten aufgeführt.

Die pico6502-Firmware benötigt die Zeta-Z80-Emulatorbibliothek nicht. Es ist kein projects/Z80-Klon erforderlich — der 6502-CPU-Kern (M6502.c) ist Teil des Projekts selbst und implementiert alle 151 offiziellen Befehle sowie alle undokumentierten Opcodes.

Zwei 6502-Modelle werden aus demselben Quellbaum wie die Z80-Modelle des picoZ80 gebaut: Base6502 (Version 2.224 — der reine MOS-6502/6512-Ersatz nur mit dem Open6502-Treiber) und BBC6502 (Version 1.049 — identischer Kern und identische Standardwerte, plus die Acorn-Treiber: die BBC-B-Persona, das UEF-Bandlaufwerk, der 8271-/WD1770-Floppy-Controller, die MMFS-Karte und das Econet-Modul). Wie jedes Z80-Modell erzeugt jedes vier Firmware-Varianten: eine pro Flash-Partition (Base6502_0x10020000, Base6502_0x10520000), jeweils mit und ohne Debug-Shell (_DBGSH). M6502.c und M6502CPU.c werden mit partieller Link-Time-Optimierung kompiliert (-flto, erhöhte Inline-Grenzen) — Teil der Geschwindigkeitskampagne. Ausgelieferte Binärdateinamen tragen die Modellversion, z.B. BBC6502_0x10020000_DBGSH_1.048.bin.

Projekt klonen

mkdir -p <root>/projects
cd <root>/projects
git clone <tzpuPico-repo-url> tzpuPico

RP2350-Firmware erstellen

Es wird dasselbe Skript build_tzpuPico.sh verwendet. Stellen Sie sicher, dass PICO_PATH am Anfang des Skripts korrekt gesetzt ist, und führen Sie es dann aus dem Stammverzeichnis aus:

cd <root>

# pico6502 vanilla firmware (Base6502 model) — four variants
./build_tzpuPico.sh 6502

# Debug build (includes the debug shell)
./build_tzpuPico.sh 6502 DEBUG

# BBC6502 (Base6502 + Acorn drivers) is built as part of the full
# all-models build; its binaries land in fw/bin/ beside the others
./build_tzpuPico.sh

Econet-Dateiserver-Daemons erstellen

tools/econet/ bündelt zwei Econet-über-IP-(AUN-)Daemons für Linux-Hosts, unverändert vom Upstream übernommen, sodass sie aus diesem Baum gebaut werden können: aund (Ben Harris' AUN-Dateiserver, BSD-Lizenz — ein Verzeichnis wird als Dateiserver im Stil eines Level 3 bereitgestellt) und econet-hpbridge (die User-Space-Bridge, der Dateiserver und der Druckserver von Chris Royles PiEconetBridge, GPLv3, hier ohne den Raspberry Pi Econet HAT gebaut, sodass er als reiner AUN-Dateiserver auf jedem PC läuft). build.sh prüft auf die benötigten Werkzeuge und nennt das zu installierende Paket, wenn eines fehlt; fileserver.sh startet einen fertig konfigurierten Server mit einem Befehl. Einrichtung und Verwendung sind im Benutzerhandbuch — Betrieb eines Econet-Dateiservers beschrieben.

# Once (Debian/Ubuntu; Fedora: gcc make autoconf automake flex libxcrypt-devel openssl-devel)
sudo apt install build-essential autoconf automake flex libcrypt-dev libssl-dev

cd <root>/projects/tzpuPico
tools/econet/build.sh            # both daemons -> tools/econet/bin/aund, tools/econet/bin/econet-hpbridge
tools/econet/build.sh aund       # or just one: aund | hpbridge
tools/econet/build.sh clean

# One-command file server (builds econet-hpbridge first if needed)
tools/econet/fileserver.sh start            # station 254 on UDP 32768, serving tools/econet/fileserver/fsroot
tools/econet/fileserver.sh status | log | stop

ESP32-Firmware separat erstellen

cd <root>/projects/tzpuPico/esp32
idf54 build

Die Definition des Docker-Alias idf54 finden Sie in der picoZ80-Build-Anleitung.

Flashen

Die Flash-Prozedur ist identisch mit der des picoZ80 — initiales RP2350-Flashen über USB-Massenspeicher, initiales ESP32-Flashen über esptool und nachfolgende Updates über die OTA-Webseiten. Vollständige Details einschließlich des esptool-Befehls und der Hinweise zu Board-Revisionen finden Sie im Abschnitt Flashen des picoZ80.

Debugging

Das Debugging des pico6502 folgt derselben Prozedur wie im Abschnitt Debugging des picoZ80 — dort finden Sie die vollständige Beschreibung der Hardware-Verbindungen, der OpenOCD-Einrichtung und der globalen GDB-Initialisierung. Die einzigen Unterschiede zum picoZ80 sind das Build-Verzeichnis der Haupt-Firmware (Base6502 statt BaseZ80) und der Eintrag add-auto-load-safe-path in ~/.gdbinit.

RP2350 — SWD-Debugging

Verbinden Sie eine CMSIS-DAP-Sonde mit SWCLK (Pin 1), SWDIO (Pin 2) und GND (Pin 5) des 6-poligen Debug-Headers. Der pico6502 verwendet dasselbe benutzerdefinierte OpenOCD-Target rp2350_tzpu.cfg wie der picoZ80 — den vollständigen Dateiinhalt finden Sie im Abschnitt Debugging des picoZ80. Installieren Sie es einmalig und starten Sie dann OpenOCD:

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

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

Fügen Sie Folgendes zu ~/.gdbinit hinzu (Pfade bei Bedarf auf absolute Pfade anpassen):

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

Bootloader-Debugging

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

# Core 1 (separate terminal)
cd build/bin/model/Bootloader
cp ../../../../.gdbinit.bootloader.3334 .gdbinit
gdb-multiarch Bootloader.elf

Debugging der Haupt-Firmware

# Core 0
cd build/bin/model/Base6502
cp ../../../../.gdbinit.3333 .gdbinit
gdb-multiarch Base6502_0x10020000.elf

# Core 1 (separate terminal)
cd build/bin/model/Base6502
cp ../../../../.gdbinit.3334 .gdbinit
gdb-multiarch Base6502_0x10020000.elf

ESP32 — USB-Debugging

Verbinden Sie ein USB-Kabel mit dem ESP32-USB-Port auf dem pico6502-Board. Das integrierte USB-JTAG-Interface des ESP32-S3 benötigt keine externe Sonde. Starten Sie OpenOCD und anschließend den Xtensa-GDB:

openocd -f board/esp32s3-builtin.cfg

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

Konfiguration (JSON)

Der pico6502 verwendet denselben JSON-Konfigurationsmechanismus wie der picoZ80. Der Schlüssel der obersten Ebene ist "rp2350", mit einem Abschnitt "core" für die RP2350-Betriebsparameter. Der CPU-spezifische Abschnitt verwendet den Schlüssel "6502" (statt "z80") und ist, genau wie "z80", ein nach Flash-Partition indiziertes Array — Index 0 ist der ungenutzte Bootloader-Slot, die Indizes 1 und 2 konfigurieren die beiden Firmware-Partitionen. Da der 6502 keinen separaten I/O-Adressraum hat, gibt es kein "io"-Array — alle Peripherie-Zuordnungen erscheinen im "memory"-Array als Blöcke vom Typ FUNC. Die Konfiguration wird beim Anwenden (Web-GUI Apply oder Reload) von der SD-Karte gelesen, minifiziert und im Flash gespeichert; das Board bootet anschließend genau wie der picoZ80 aus der Flash-Kopie.

{
  "esp32": {
    "core": {
      "device": "6502",
      "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
    },
    "6502": [
      { },
      {
        "cputype":     "6502",
        "dbeoverride": true,
        "core":        { "cpufreq": 340000000, "psramfreq": 133000000, "voltage": 1.20 },
        "memory":      [ ... ],
        "drivers":     [ ... ]
      }
    ]
  }
}

esp32 — ESP32-Konfiguration

Das Objekt esp32 der obersten Ebene konfiguriert den ESP32-Co-Prozessor. Es enthält zwei Unterobjekte: core und wifi.

esp32.core

Schlüssel	Typ	Beschreibung
`device`	string	CPU-Gerätetyp — teilt dem ESP32 mit, welche Prozessor-Persönlichkeit zu verwenden ist. Gültige Werte: `"Z80"` (picoZ80), `"6502"` (pico6502), `"6512"` (pico6512).
`mode`	integer	Standard-Bootmodus: `0` = Client-(Station-)Modus, `1` = Access-Point-Modus. Wird im NVS persistiert.

esp32.wifi

Das Objekt wifi injiziert WiFi-Zugangsdaten und Netzwerkeinstellungen aus config.json und überschreibt, was im NVS gespeichert ist. Setzen Sie override auf 0, um diesen Block zu ignorieren und sich auf zuvor persistierte NVS-Einstellungen zu verlassen.

Schlüssel	Typ	Beschreibung
`override`	0/1	Hauptschalter. `1` = alle untenstehenden Einstellungen anwenden; `0` = diesen Block ignorieren und persistierte NVS-Einstellungen verwenden.
`wifimode`	string	`"ap"` für den Access-Point-Modus; `"client"` für den Client-/Station-Modus.
`ssid`	string	Name des WiFi-Netzwerks, das erstellt (AP) oder beigetreten (Client) werden soll.
`password`	string	WiFi-Passphrase.
`ip`	string	Feste IP-Adresse (z.B. `"192.168.1.192"`).
`netmask`	string	Subnetzmaske (z.B. `"255.255.255.0"`).
`gateway`	string	Adresse des Standard-Gateways.
`dhcp`	0/1	Nur Client-Modus. `1` = DHCP; `0` = feste `ip`/`netmask`/`gateway` verwenden.
`webfs`	string	Überschreibt das Stammverzeichnis des Web-Dateisystems auf der SD-Karte (Standard `"webfs"`).
`persist`	0/1	`1` = aufgelöste Einstellungen zurück in den NVS schreiben; `0` = nur für diese Sitzung anwenden.

core — RP2350-Betriebsparameter

Schlüssel	Typ	Beschreibung
`cpufreq`	integer	RP2350-Systemtaktfrequenz in Hz (z.B. `340000000` für die BBC-Persona, `150000000` für die Vanilla-Persona). Ein Boot, der am Watchdog hängen bleibt, fällt auf einen abgesicherten 150-MHz-Modus zurück.
`psramfreq`	integer	PSRAM-SPI-Taktfrequenz in Hz (z.B. `133000000` für 133 MHz).
`voltage`	float	RP2350-Kernspannung (z.B. `1.20`). Die Reserve ist boardabhängig: 340 MHz laufen auf der Referenzeinheit mit 1,20 V, 330 MHz benötigten auf einem anderen Board ~1,35 V. Erhöhen Sie die Spannung, bevor Sie etwas anderem die Schuld geben.

Dieselben drei Schlüssel können in einem "core"-Objekt innerhalb jedes Partitionseintrags wiederholt werden; die Web-GUI speichert Takt und Spannung einer Partition dort, und der globale Block ist nur der Fallback. Beide werden beim Booten protokolliert (CFG: partition N core: ...).

6502 — CPU-Partitionseintrag

Jeder Eintrag des "6502"-Partitions-Arrays trägt die CPU-Auswahl zusammen mit der Speicherbelegung und den Treibern:

Schlüssel	Typ	Beschreibung
`cputype`	string	`"6502"`, `"6512"`, `"65C02"` oder `"65C12"`. 6502 und 6512 sind oberhalb der Pins derselbe NMOS-Prozessor — identische Register, identischer Befehlssatz (einschließlich der undokumentierten Opcodes) und identisches Zyklus-Timing — und unterscheiden sich nur in der Taktung: Der 6502 hat den On-Chip-Taktgenerator (PHI0 hinein, PHI1/PHI2 von der Firmware hinausgetrieben); der 6512 hat keinen und übernimmt vom Host gelieferte Phasen. Die `C`-Varianten wählen dieselbe Taktung mit dem CMOS-Befehlssatz-Overlay.
`dbeoverride`	boolean	Steuert den `DBE_OVR`-Buffer-Enable-Override des gepufferten v2.3-Interfaces (`~EN = NOR(DBE, DBE_OVR)`, wobei `DBE_OVR` vom ESP32 getrieben wird). Die mitgelieferten 6502-Personas setzen `true` (ein 6502-Host hat keinen DBE-Pin); die GUI schaltet ihn für einen 6512 standardmäßig aus — siehe Technisches Handbuch.
`core`	object	`cpufreq` / `psramfreq` / `voltage` Override pro Partition (siehe oben).
`ioparkaddr`	hex string	Adresse, auf der die Bus-Engine nach einem I/O-Zugriff parkt, wenn das Adressparken aktiviert ist. Standard ist `0xFFFC` (der Reset-Vektor — auf jedem bootfähigen 6502 abgebildetes ROM), sobald ein `PHYSICALHW`-Bereich deklariert ist.
`memory`	array	Die Speicherbelegung — siehe unten.
`drivers`	array	Treibereinträge, jeder optional mit ROM-Images, Bus-Engine-Tuning-Overrides und Maschinenoptionen — siehe unten.

memory — Speicherbelegung

Da der 6502 eine Architektur mit speicherabgebildeter I/O ist, erscheinen alle Peripheriegeräte im memory-Array. Verwenden Sie den Typ FUNC für jeden Adressbereich, der auf einen Handler eines virtuellen Geräts abgebildet wird.

Schlüssel	Typ	Beschreibung
`enable`	0/1	Ob dieser Eintrag aktiv ist.
`addr`	hex string	Startadresse im 6502-Adressraum.
`size`	hex string	Größe des Bereichs.
`type`	string	`PHYSICAL`, `PHYSICALVRAM`, `PHYSICALHW`, `RAM`, `VRAM`, `ROM`, `FUNC`.
`bank`	integer	PSRAM-Banknummer für RAM-/ROM-Typen.
`task`	string	Optionale Aufgabenkennung: `COPYTOPHYSICAL` / `COPYTORAM` kopieren den Bereich bei der Initialisierung zwischen Host-Speicher und PSRAM.
`file`	string	SD-Karten-Pfad zu einem ROM-Image, das beim Booten geladen wird.

"memory": [
  {
    "enable": 1,
    "addr":   "0xE000",
    "size":   "0x2000",
    "type":   "ROM",
    "bank":   0,
    "task":   "",
    "file":   "/ROM/host_bios.rom"
  },
  {
    "enable": 1,
    "addr":   "0x0000",
    "size":   "0xE000",
    "type":   "RAM",
    "bank":   0,
    "task":   "",
    "file":   ""
  },
  {
    "enable": 1,
    "addr":   "0xC000",
    "size":   "0x0010",
    "type":   "FUNC",
    "bank":   0,
    "task":   "via6522",
    "file":   ""
  }
]

drivers — Maschinentreiber, ROM-Loader und Bus-Tuning

Jeder Treibereintrag wählt einen Maschinentreiber nach Namen (Open6502 oder BBC-B), lädt optional beim Start ROM-Images in das PSRAM und kann das Bus-Engine-Tuning überschreiben, das der Treiber als eingebaute Standardwerte anwendet. Es gibt keine Untertabellen für Adress- oder I/O-Remapping; das gesamte Speicherlayout wird im memory-Array definiert. Das Maschinenwissen gehört dem Treiber: Die Standardwerte des BBC-B-Treibers gelten, wenn er ausgewählt ist, und jeder der untenstehenden Tuning-Schlüssel im Treiberobjekt überschreibt sie (das Panel Bus Engine Tuning der Web-GUI schreibt genau diese Schlüssel, und nur die, die Sie setzen).

Schlüssel	Typ	Beschreibung
`enable`	0/1	Ob dieser Treibereintrag aktiv ist.
`name`	string	Treibername, ohne Beachtung der Groß-/Kleinschreibung gegen die Treibertabelle der Firmware abgeglichen: `Open6502`, `BBC-B`.
`rom`	array	ROM-Images, die beim Booten in das PSRAM geladen werden.
`ioregionlo` / `ioregionhi`	integer	Das I/O-Fenster des Hosts. Seine Deklaration ist es, die die Spekulation aktiviert — die Engine burstet niemals hinein oder darüber hinweg. (BBC-B-Standard `0xFC00`–`0xFF00`.)
`shadowwrlo` / `shadowwrhi`	integer	Adressbereich, dessen einziger Schreiber diese CPU ist, gehalten als Write-Through-Shadow; Schreibzugriffe außerhalb invalidieren nur (Sideways-ROM ignoriert Schreibzugriffe). (BBC-B-Standard `0x0000`–`0x8000`.)
`pageregaddr` / `pageregmask`	integer	Das Paging-Register und seine Dekodiermaske; ein Schreibzugriff darauf invalidiert den gepagten Bereich. (BBC-B: ROMSEL `0xFE30`, Maske `0xFFF0`.)
`pageregionlo` / `pageregionhi`	integer	Der Bereich, den das Paging-Register umschaltet. (BBC-B-Standard `0x8000`–`0xC000`.)
`burstspec`	1–6	Tiefe des spekulativen Opcode-Bursts. (BBC-B-Standard 6, MMFS-sicher, sobald ROMSEL deklariert ist.)
`busserve` / `buspipe` / `fastfetch`	boolean	Tri-State-Overrides (nicht vorhanden = Treiberstandard) für Shadow-Serve, den gepipelineten Issue-Pfad und den schnellen Opcode-Fetch.

Der BBC-B-Treiber akzeptiert seine Maschinenoptionen ebenfalls im selben Objekt:

Schlüssel	Typ	Beschreibung
`modelaram`	boolean	Model-A-Host: 16K PSRAM-gestütztes RAM bei `$4000–$7FFF` überlagern, sodass das OS eine 32K-Maschine sieht (Programm-/Datenbereich; das Bildschirmverhalten auf einem Model A ist noch zu verifizieren).
`mastermode`	boolean	BBC-Master-128-Speichermodell — LYNNE 20K Shadow, HAZEL 8K, ANDY 4K, mit virtualisiertem ACCCON (`$FE34`). Erwartet ein MOS-3.x-Image im OS-Sockel und erzwingt den CMOS-Kern.
`ossocket`	object	`{ "enable", "file", "fileoffset" }` — ein 16K-OS-ROM, virtualisiert über `$C000–$FFFF`; das I/O-Fenster wird stets an den Bus durchgereicht, und die Vektoren `$FF00–$FFFF` stammen aus dem Image. `fileoffset` wählt das OS innerhalb eines größeren (MegaROM-)Images aus.
`sockets`	array	`{ "socket" 0–15, "enable", "ram", "file", "fileoffset", "persist" }` — virtuelle Sideways-ROM/RAM-Sockel. Ein aktivierter Sockel überschreibt die physische Bank: `ram: true` ist 16K Sideways-RAM, andernfalls ist `file` ein 16K-ROM-Image. Der ROMSEL-Schreibzugriff erreicht weiterhin das Hardware-Latch.
`presetdiscroms`	boolean	Bänke 9 (DFS) und 13 (ADFS) aus einem Master-MegaROM füllen.
`persist`	string	`"sd"` (Standard), `"flash"` oder `"off"` — wo die Inhalte des virtuellen CMOS und des Sideways-RAM gespeichert werden.
`if`	array	Bindbare Interfaces. `CMT-UEF`: `{ "name": "CMT-UEF", "speed": ..., "param": [ { "file": "cmt/tape.uef" }, ... ] }` — das Bandlaufwerk mit bis zu sechs Slots. `BBC-FDC`: `{ "name": "BBC-FDC", "chip": "8271\|1770", "board": "acorn\|master\|watford", "speed": 0, "param": [ drive 0 side A, drive 0 side B, drive 1 side A, drive 1 side B ] }` — `chip` wählt den Intel 8271 (Standard, `$FE80`) oder einen WD1770; `board` (nur 1770) wählt Latch und Registerdekodierung: `acorn` (Model B Upgrade Board, Latch `$FE80`, Chip `$FE84`), `master` (Master 128, Latch `$FE24`, Chip `$FE28` — standardmäßig aktiv, wenn `mastermode` gesetzt ist, und erlaubt das Vorbelegen der DFS-/ADFS-Bänke des Master-MOS) oder `watford`. Jeder Slot ist `{ "file": "dsk/x.ssd", "type": "auto\|ssd\|dsd\|mmb\|adf\|adl\|dds\|ddd" }`; ein doppelseitiges Image (`dsd`, `adl`, `ddd` oder ein `adf`-L-Image) in einem Seite-A-Slot liefert beide Seiten, ein zweites einseitiges Image im Seite-B-Slot paart zwei Dateien zu einer doppelseitigen Diskette, `mmb/BEEB.MMB:<n>` wählt eine Diskette aus einem Bundle, `auto` leitet die Art aus Erweiterung und Größe ab; `"speed": 1` fügt mechanisches Hochlauf-, Seek-, Settle- und Rotations-Timing hinzu. `BBC-MMC`: `{ "name": "BBC-MMC", "param": [ { "file": "mmb/BEEB.MMB" } ] }` — das MMB-Image hinter der virtuellen MMFS-Karte. `BBC-NET`: `{ "name": "BBC-NET", "station": 0, "net": 0, "aunport": 32768, "server": "192.168.1.210:32768", "serverstation": 254, "servernet": 0, "hosts": [ { "station": 10, "ip": "192.168.1.50", "port": 32768 } ] }` — das Econet-Modul; `station` 0 übernimmt das niederwertige Byte der IP-Adresse des pico6502 (die AUN-Konvention), `server` ist die Adresse des Dateiservers (leer = `<subnet>.254:32768`), und `hosts[]` ordnet jede Station zu, die der Konvention nicht folgt.

rom[]-Eintrag:

Schlüssel	Typ	Beschreibung
`enable`	0/1	Ob dieses ROM-Image geladen wird.
`file`	string	SD-Karten-Pfad zur ROM-Binärdatei.
`loadaddr`	array	Ladeadress-Deskriptoren.

loadaddr[]-Eintrag:

Schlüssel	Typ	Beschreibung
`enable`	0/1	Ob dieser Ladeadress-Eintrag aktiv ist.
`position`	integer	Index innerhalb der `file` (für Multi-ROM-Dateien).
`addr`	hex string	Zieladresse im 6502-Adressraum.
`bank`	integer	PSRAM-Bank, in die geladen wird.
`size`	hex string	Anzahl der zu ladenden Bytes.

"drivers": [
  {
    "enable": 1,
    "name":   "BIOS",
    "rom": [
      {
        "enable":   1,
        "file":     "/ROM/host_bios.rom",
        "loadaddr": [
          {
            "enable":   1,
            "position": 0,
            "addr":     "0xE000",
            "bank":     0,
            "size":     "0x2000"
          }
        ]
      }
    ]
  },
  {
    "enable": 1,
    "name":   "CharROM",
    "rom": [
      {
        "enable":   1,
        "file":     "/ROM/charrom.bin",
        "loadaddr": [
          {
            "enable":   1,
            "position": 0,
            "addr":     "0xB800",
            "bank":     0,
            "size":     "0x0800"
          }
        ]
      }
    ]
  }
]

Vollständige Konfigurationsbeispiele

Eine minimale Konfiguration für einen generischen 6502-Host mit einem 2KB-Zero-Page-/Stack-RAM-Bereich, 48KB allgemeinem RAM, einem 8KB-BIOS-ROM und einem VIA-Peripherie-Handler bei 0xC000:

{
  "rp2350": {
    "core": {
      "cpufreq":   150000000,
      "psramfreq": 133000000,
      "voltage":   1.15
    },
    "6502": [
      { },
      {
        "cputype":     "6502",
        "dbeoverride": true,
        "memory": [
          { "enable":1, "addr":"0x0000", "size":"0x0200",
            "type":"RAM", "bank":0, "task":"", "file":"" },
          { "enable":1, "addr":"0x0200", "size":"0xBE00",
            "type":"RAM", "bank":0, "task":"", "file":"" },
          { "enable":1, "addr":"0xC000", "size":"0x0010",
            "type":"FUNC", "bank":0, "task":"via6522", "file":"" },
          { "enable":1, "addr":"0xE000", "size":"0x2000",
            "type":"ROM", "bank":0, "task":"", "file":"/ROM/host_bios.rom" }
        ],
        "drivers": [
          {
            "enable":1, "name":"Open6502",
            "rom": [
              { "enable":1, "file":"/ROM/host_bios.rom",
                "loadaddr":[{ "enable":1, "position":0,
                              "addr":"0xE000", "bank":0, "size":"0x2000" }] }
            ]
          }
        ]
      }
    ]
  }
}

Die mitgelieferte BBC-Model-B-Persona: vollständiges physisches Passthrough bei 340MHz, das Maschinenwissen vom Treiber beigesteuert, mit MMFS aus einem virtuellen Sideways-Sockel und einem Band im UEF-Laufwerk:

{
  "rp2350": {
    "core": { "voltage": 1.20, "cpufreq": 340000000, "psramfreq": 133000000 },
    "6502": [
      { },
      {
        "cputype":     "6502",
        "dbeoverride": true,
        "core":    { "voltage": 1.20, "cpufreq": 340000000, "psramfreq": 133000000 },
        "memory":  [ ],
        "drivers": [ {
          "enable":     1,
          "name":       "BBC-B",
          "modelaram":  false,
          "mastermode": false,
          "ossocket":   { "enable": 0, "file": "" },
          "sockets":    [ { "socket": 12, "enable": 1, "ram": false,
                            "file": "roms/bbc/MMFS.rom" } ],
          "if":         [ { "name": "CMT-UEF", "enable": 1,
                            "param": [ { "file": "cmt/Elite.uef" } ] },
                          { "name": "BBC-FDC", "enable": 1, "speed": 0,
                            "chip": "1770", "board": "acorn",
                            "param": [ { "file": "dsk/ACORN3_A.ssd", "type": "ssd" },
                                       { "file": "dsk/ACORN3_B.ssd", "type": "ssd" },
                                       { "file": "adfs/Apps.adl",    "type": "adl" },
                                       { "file": "" } ] },
                          { "name": "BBC-MMC", "enable": 1,
                            "param": [ { "file": "mmb/BEEB.MMB" } ] },
                          { "name": "BBC-NET", "enable": 1,
                            "station": 0, "net": 0, "aunport": 32768,
                            "server": "192.168.1.210:32768", "serverstation": 254 } ],
          "rom":        [ ]
        } ],
        "device":    [ ],
        "interlink": [ ]
      }
    ]
  },
  "esp32": {
    "core": { "device": "6502", "mode": 0 },
    "wifi": { "ssid": "p6502", "password": "p6502p6502", "ip": "192.168.4.4",
              "netmask": "255.255.255.0", "gateway": "192.168.4.1",
              "wifimode": "ap", "dhcp": 1, "override": 1, "webfs": "webfs", "persist": 0 }
  }
}

Debug-Shell (ICE)

Der pico6502 trägt dieselbe integrierte Debug-Shell (ICE) wie der picoZ80 — eine CPU-neutrale Shell, die über eine CPU-spezifische Operationstabelle verteilt, sodass Befehlssatz und Verhalten auf beiden Boards gemeinsam sind. Auf dem 6502 bietet sie 61 Befehle (62 im BBC6502-Build, der bbc hinzufügt); die I/O-Adressraum-, Geräte-Framework- und Z80-Peripherie-Befehle des Z80 sind nicht anwendbar. Sie deckt Register (A/X/Y/S/PC, Flags NV-BDIZC), Einzelschritt und Step-over, Haltepunkte (einschließlich Break-before-Execute mit einmaligem Fortsetzen), Speicheranzeige/-bearbeitung sowie einen vollständigen 6502-Disassembler und Einzeilen-Assembler ab — die Opcode-Tabelle wird aus der Dekodierlogik des Emulators selbst generiert, sodass das, was Sie disassemblieren, genau das ist, was ausgeführt wird; undokumentierte Opcodes werden mit dem Präfix * angezeigt, das CMOS-Overlay wird disassembliert, wenn ein C-Typ gewählt ist, und disdesc hängt an jedes Mnemonic eine Klartextbeschreibung an.

Die 6502-spezifischen Befehle gliedern sich in drei Gruppen:

Board-Bring-up
- busdiag (Momentaufnahme jedes Sockelsignals; busdiag clk vergleicht PHI0 mit den zurückgeführten PHI1_IN/PHI2_IN, um einen defekten Puffer von einem fehlenden Takt zu unterscheiden; busdiag watch [n] für Signale in Bewegung), busprobe <addr> (liest eine Adresse wiederholt, um instabile Datenleitungen aufzudecken), busverify <addr> <len> (ROM-sicheres erneutes Lesen eines Bereichs, das wackelige Lesezugriffe und Fetch-/Read-Abweichungen meldet), memtest (einschließlich eines decay-Modus für den DRAM-Refresh), bustest und wrtest (treiben markierte Muster für einen Logikanalysator), busstate (Live-Zustand der PIO-Engine für die Hang-Forensik) und piodbg.

Bus-Engine-Stellschrauben
- writestrobes <1|2> (1 ist Vanilla), iopark on|off, readsettle <0-31>, readphase latch|hi|lo und buspipe mit den Unterbefehlen on|off, fetch, rungs, burst <1-6>, iochase, iorange <lo> <hi>, serve, natwr, wrregion, wrhold, wrverify, slowclr und stats — die Live-A/B-Schalter, mit denen die Geschwindigkeitskampagne durchgeführt wurde. pipetest <iters> führt den Verifikations-Harness für gemischte Busoperationen auf Core 1 aus.

Performance und Persona
- cpustat (Befehle/s und emulierte Zyklen/s gegenüber dem gemessenen Host-Takt — zweimal aufrufen), cpuprof (Zeithistogramm pro Befehl nach Busklasse) und im BBC6502-Build bbc (mask, socket <n> <0|1>, cmosdef, oscheck, tape sel|next|rew|trace|on|off für das UEF-Laufwerk, fdc <drive> <file|eject> [A|B] [auto|ssd|dsd|mmb|adf|adl|dds|ddd] / fdc trace on|off für den Floppy-Controller, mmc / mmc trace on|off für die MMFS-Karte und net / net trace on|off für das Econet-Modul — Frames, UDP ein/aus, Bestätigungen, Timeouts und Antwortlatenz).

Die Verwendung ist im Benutzerhandbuch — ICE (Debug-Shell) beschrieben.

Host-Simulator (pico6502sim)

pico6502sim kompiliert die echte pico6502-Firmware — die RP2350-Quellen und die ESP32-Hälfte mit ihrer Weboberfläche und virtuellen SD-Karte — nativ für einen PC und führt sie headless aus. Er ist eigenständig (kein externes Emulator-Framework; ein C/C++-Compiler, pthreads und zlib genügen) und ist der Weg, auf dem die Firmware erprobt wurde, während das v2.3-Board geroutet wurde; heute dient er als Regressionsumgebung und als der Ort, an dem neue Treiber geschrieben werden — LOAD und SAVE des UEF-Bandlaufwerks wurden gegen den simulierten BBC erprobt, bevor sie auf Hardware kamen. Die Debug-Shell, die Personas, das Parsen der Konfiguration, die ESP32-Verbindung und die vom Browser bediente Web-GUI laufen alle echt; der Bus ist entweder ein offener Sockel (Lesezugriffe liefern 0xFF, was genau wie bei einem echten, nicht angeschlossenen 6502 frei läuft) oder ein synthetischer Host-Rechner.

Der Launcher (sim/run.sh) stellt drei Maschinen bereit, die alle gleichzeitig laufen können:

Maschine	CPU	Host-Takt	Web-GUI-Port	Host-Modell
`apple1`	6502	1,023 MHz	8110	Synthetischer Apple I: 32KB RAM, 6821 PIA bei `$D010-$D013` (gespiegelt über `$D000-$DFFF`), 8KB-ROM-Fenster `$E000-$FFFF`; Terminal auf einem virtuellen seriellen Port.
`bbcmodelb`	6502	2 MHz	8111	Synthetischer BBC Model B (`sim/src/host_bbc.c`): 32K RAM, 16 Sideways-Bänke über ROMSEL, MOS + BASIC + DFS aus `SD/default/roms/BBC/`, System-6522-VIA mit Timern, IFR/IER, IC32-Latch und Tastaturmatrix (von B-em portiert), 50 Hz Vsync; Tastatur auf einem virtuellen seriellen Port und MODE 7-Teletext live als ANSI auf demselben Terminal gerendert. CRTC-/Video-ULA-Register werden nur gespeichert, User VIA, FDC, Econet und Tube werden als nicht vorhanden gelesen. Mit den Acorn-Treibern gebaut, sodass die BBC-B-Persona und das UEF-Laufwerk laufen.
`bbcmaster`	65C12	2 MHz	8112	Keines (headless). Läuft auf dem CMOS-Kern.

Es wird kein Apple-ROM mitgeliefert (der Woz-Monitor gehört Apple); run.sh durchsucht die Verzeichnisse roms/APPLE1/ und roms/BBC/ der SD-Karte, und --rom= überschreibt dies. Ohne Apple-ROM läuft ein kleines eingebautes Banner-/Echo-Programm — genug, um Fetch, Execute, Branch, Call und den PIA in beiden Richtungen zu beweisen. Die Host-API erlaubt einem Modell, /IRQ und /NMI zu setzen, und die simulierte 6502-Persona wird genau wie auf der Hardware über die Web-GUI angewendet (Apply schreibt den Flash-Speicher und startet neu).

Der Simulator beweist Logik, nicht Timing — er modelliert keinen Takt, keine PHI1/PHI2-Phasen, keine Setup- oder Hold-Zeiten und keine Buskonflikte. Ein sauberer Lauf validiert Firmware, Personas und Weboberfläche; alles, was den Bus selbst betrifft, wurde auf dem v2.3a-Board mit einem Logikanalysator ermittelt.

Weboberfläche

Die pico6502-Weboberfläche ist in ihrer Struktur identisch mit der picoZ80-Oberfläche — acht Bootstrap-4-Seiten, die vom ESP32 unter http://<device-ip>/ bereitgestellt werden. Verbinden Sie sich beim ersten Boot mit dem WiFi-AP des Boards und konfigurieren Sie dann über den WiFi-Manager den Client-Modus, um Ihrem Netzwerk beizutreten.

Seite	URL	Funktion
Dashboard	`/`	Echtzeit-Systemstatus: Prozessor, Gerät, Firmware-Version, aktive Partition. Auf einem 6502-Host sind die nur für Z80 relevanten CMT- und Quick-Disk-Menüs ausgeblendet, und das Floppy-Menü zeigt die beiden Laufwerke des virtuellen 8271 als Drive 0 / Drive 1, Side A / Side B — ein Image live wechseln oder auswerfen, wobei die Image-Art (auto / SSD / DSD / MMB / ADF / ADL / DDS / DDD) pro Seite gewählt wird.
Konfigurations-GUI	`/configgui.htm`	Strukturierter Editor für die gesamte Konfiguration. Für eine 6502-Partition: `cputype` (6502 / 6512 / 65C02 / 65C12) und `dbeoverride`; Kernspannung pro Partition (0,85–1,50 V), `cpufreq` (100–400 MHz, warnt oberhalb von 330) und `psramfreq`; Pad-Treiberstärke pro Busgruppe; der Speicherbelegungs-Editor; der Treiberabschnitt mit einem Panel Bus Engine Tuning pro Treiber (I/O-Fenster, Shadow-Write-Fenster, Paging-Register und -Bereich, Burst-Tiefe, Serve / Pipeline / Fast-Fetch); die BBC-B-Maschinenoptionen (Model-A-RAM, Master-Modus, vorbelegte Disketten-ROMs, Persistenz) und die Tabelle Sideways ROM / RAM Sockets (OS-Sockel plus Sockel 0–15 mit RAM-Flag, ROM-Image-Browser, MegaROM-Offset und Speicherziel); sowie das `CMT-UEF`-Bandkarussell mit sechs Slots, das `BBC-FDC`-Floppy-Interface mit seinen Auswahlfeldern für Chip (8271 / WD1770) und Board (Acorn / Master 128 / Watford) und vier festen Slots (Drive 0 · Side A/B, Drive 1 · Side A/B, jeweils mit Art-Auswahl), die `BBC-MMC`-MMFS-Karte mit ihrem MMB-Image und das `BBC-NET`-Econet-Modul mit Stationsnummer, Dateiserver-Adresse, Dateiserver-Station und AUN-Port. Der I/O-Abschnitt ist ausgeblendet, da der 6502 keinen I/O-Adressraum hat.
Config-Editor	`/config.htm`	Roh-Editor für `config.json` im Browser mit Syntaxhervorhebung und Reload ohne Neustart.
Dateimanager	`/filemanager.htm`	SD-Karten-Dateibrowser: Hochladen, Herunterladen, Umbenennen, Löschen. ROM-Images und Disk-Images übertragen, ohne die SD-Karte zu entnehmen.
Persona-Auswahl	`/personality.htm`	Aktive Maschinen-Persona pro Firmware-Partition auswählen.
ESP32 OTA	`/ota-esp32.htm`	ESP32-Firmware über WiFi hochladen; versioniertes FilePack-Web-Dateisystemarchiv auf die SD-Karte hochladen.
RP2350 OTA	`/ota-rp2350.htm`	RP2350-Firmware über WiFi hochladen; aktive Partition anzeigen und umschalten.
WiFi-Manager	`/wifimanager.htm`	WiFi-SSID, Passwort und Modus (AP oder Client) konfigurieren.

Eine detaillierte Beschreibung jeder Seite der Weboberfläche finden Sie auf der picoZ80-Seite — die pico6502-Implementierung ist identisch.

Referenzseiten

Die folgende Tabelle enthält alle Websites, auf die beim Design und bei der Programmierung des pico6502 Bezug genommen wurde.

Website	Sprache	Beschreibung
RP2350 Datasheet	Englisch	Offizielle technische Referenz und Datenblatt zum Raspberry Pi RP2350.
Pico SDK	Englisch	Raspberry Pi Pico C/C++ SDK — Build-System und Hardware-Abstraktion, die von der pico6502-Firmware verwendet werden.
MOS 6502 Datasheet	Englisch	Originales Datenblatt der MOS Technology 6502 MPU — Bus-Timing, Pin-Beschreibungen und elektrische Eigenschaften.
ESP-IDF	Englisch	Espressif IoT Development Framework, das für die Firmware des ESP32-Co-Prozessors verwendet wird.
6502 Software Repository	Englisch	Community-Repository für 6502-Software und ROM-Images.

Handbücher und Datenblätter

Die folgende Tabelle enthält alle Datenblätter und Handbücher, auf die beim Design und bei der Programmierung des pico6502 Bezug genommen wurde.

Datenblatt	Sprache	Beschreibung
RP2350	Englisch	Datenblatt des Raspberry Pi RP2350-Mikrocontrollers.
ESP32-S3	Englisch	Datenblatt des Espressif ESP32-S3 SoC — WiFi/BT-Co-Prozessor auf dem pico6502-Board.
APS6404L PSRAM	Englisch	Datenblatt des 8MB SPI PSRAM — das wichtigste erweiterte RAM, das für das Speicher-Banking verwendet wird.
W25Q128 Flash	Englisch	Datenblatt des Winbond 16MB SPI NOR Flash — speichert Firmware und ROM-Images.
TLV62590	Englisch	Texas Instruments 5V→3,3V-Synchron-Abwärtswandler, der den pico6502 vom VCC-Pin des 6502 DIP-40 versorgt.
CH334F	Englisch	CH334F 4-Port-USB-2.0-Hub-Controller — stellt die USB-Hub-Funktionalität für Firmware-Updates bereit.

Projektvorschau

Die Projekte picoZ80 und pico6502 wurden erstmals auf X (ehemals Twitter) vorgestellt:

https://x.com/engineerswork1/status/1953171627065188841

Demonstrationsvideos

Demonstrationsvideos für den pico6502 werden hinzugefügt, sobald das Projekt reift. Beispiele für die gemeinsame Plattform in Aktion finden Sie in den picoZ80-Demonstrationsvideos.

Kommerzielle Nutzungsbeschränkung

Keine kommerzielle Nutzung ohne ausdrückliche schriftliche Genehmigung gestattet.

Das pico6502-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 pico6502-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), die vom Schwesterprojekt picoZ80 verwendet wird. Dieselbe hochpräzise Emulationsphilosophie und die gemeinsame Firmware-Infrastruktur prägen das pico6502-Design, und Manuels Arbeit wird als Teil der größeren Projektfamilie dankbar anerkannt.

Raspberry Pi Ltd
Autoren des Pico SDK und der RP2350-Hardware. Der PIO-Assembler, das C SDK, die CMake-Toolchain-Integration und das RP2350B-Silizium machen das zyklusgenaue 6502-Bus-Interface 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 und die gesamte Projektdokumentation.

Grok (xAI)
KI-Assistent, der wertvolle Hilfe beim Debugging der PIO-Zustandsmaschinen leistete — insbesondere bei der Diagnose von Timing-Grenzfällen und zyklusgenauen 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 pico6502-Projekt besteht aus mehreren Komponenten, die jeweils unter ihrer eigenen Lizenz stehen:

Komponente	Lizenz
pico6502 RP2350-Firmware (PIO, C-Quellen)	GNU General Public License v3
pico6502 ESP32-Firmware und Weboberfläche	GNU General Public License v3
KiCad-Hardware-Designdateien (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 (Weboberfläche)	MIT License

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 LICENSE und NOTICE im Repository für vollständige Details.

Lizenzbestimmungen

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 NOTICE im Repository für vollständige Details.

Kommerzielle Lizenzierung
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 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 sendet, wodurch es 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).

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 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.

Der Bau dieses Projekts für den persönlichen Gebrauch in begrenzter Stückzahl 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.

Verantwortung des Bauherrn
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.