tranZPUter FusionX Entwicklerhandbuch

Uebersicht

Der tranZPUter FusionX Software-Stack ist in drei verschiedene Schichten organisiert, die zusammen ein vollstaendiges Z80-Emulations- und virtuelles Hardware-System bilden. Jede Schicht hat eine klar definierte Verantwortung, und das Hinzufuegen von Unterstuetzung fuer eine neue Host-Maschine — oder die Erweiterung einer bestehenden — erfordert koordinierte Aenderungen ueber alle drei Schichten.
  1. Linux-Kernelmodule (z80drv.ko, ttymzdrv.ko) — in C geschrieben, gegen den SigmaStar Linux 4.9-rt Kernel-Baum gebaut. z80drv fuehrt die Z80-Emulations-Dispatch-Schleife auf einem isolierten CPU-Kern aus und kommuniziert mit dem CPLD ueber SPI und GPIO. ttymzdrv bietet eine TTY-Schnittstelle zur Sharp MZ Tastatur- und Zeichenanzeige-Hardware.
  2. User-Space-Dienstprogramme (z80ctrl, k64fcpu, sharpbiter) — in C geschrieben, Cross-kompiliert mit arm-linux-gnueabihf-gcc. Diese Dienstprogramme starten, stoppen und konfigurieren das Kernelmodul zur Laufzeit; k64fcpu agiert als Daemon, der die K64F virtuelle CPU-Schnittstelle emuliert; sharpbiter vermittelt den Zugriff auf Tastatur und Display zwischen der Host-Maschinen-Software und der Linux-Konsole.
  3. CPLD RTL (VHDL) — erstellt mit Altera Quartus II 13.0.1 SP1 Web Edition. Das CPLD sitzt direkt auf dem Z80-Bus der Host-Maschine und fungiert als Hardware-Schnittstelle zwischen den physischen Z80-Bussignalen und dem SigmaStar SOM (System-on-Module). Es erfasst jeden Buszyklus, signalisiert dem SOM und treibt den Z80-Datenbus im Auftrag des SOM fuer Lesezyklen.
Das Hinzufuegen von Unterstuetzung fuer eine neue Maschine erfordert Aenderungen an allen drei Schichten: eine neue Speicherabbildungsdefinition und ein virtuelles Hardware-Modul im Kerneltreiber, eine neue CPLD-VHDL-Variante, die fuer den Busstecker und das Timing der Zielmaschine kompiliert wird, und ein Startskript, das beides verbindet.

Quellbaum

Der gesamte Quellcode ist unter dem FusionX/-Repository-Stammverzeichnis organisiert. Das unten gezeigte Verzeichnislayout zeigt die Schluesseldateien, mit denen ein Entwickler arbeiten muss. Build-Varianten-Verzeichnisse (src.mz80a/, src.mz700/ usw.) enthalten ein Makefile und symbolische Links zu den gemeinsamen Quelldateien in src/; nur maschinenspezifische Dateien unterscheiden sich zwischen den Varianten.
FusionX/
├── CPLD/
│   └── v1.0/
│       ├── MZ80A/build/          Quartus II project for Sharp MZ-80A
│       ├── MZ700/build/          Quartus II project for Sharp MZ-700
│       ├── MZ2000/build/         Quartus II project for Sharp MZ-2000
│       ├── PCW8256/build/        Quartus II project for Amstrad PCW-8256
│       ├── tzpuFusionX.vhd           Main RTL (FSMs, SPI, bus interface, video/audio)
│       ├── tzpuFusionX_Toplevel.vhd  Top-level entity and I/O pin assignments
│       └── tzpuFusionX_pkg.vhd       Shared package (types, constants, generics)
└── software/
    ├── linux/
    │   └── Build_FusionX.sh      Master build script (U-boot + kernel + rootfs + apps)
    └── FusionX/
        └── src/
            ├── z80drv/
            │   ├── src.mz80a/    Makefile and symlinks for MZ-80A build variant
            │   ├── src.mz700/    MZ-700 build variant
            │   ├── src.mz2000/   MZ-2000 build variant
            │   ├── src.pcw/      PCW-8256 build variant
            │   └── src/          Common source files:
            │       ├── z80driver.c      Main kernel module: dispatch loop, memory/IO routing
            │       ├── z80driver.h      Data structures, memory map constants per machine
            │       ├── z80io.c          HAL: SPI write path, GPIO read path, CPLD communication
            │       ├── emumz.c          Zeta Z80 instruction execution wrapper
            │       ├── z80vhw_mz80a.c   MZ-80A virtual hardware
            │       ├── z80vhw_mz700.c   MZ-700 virtual hardware
            │       ├── z80vhw_mz2000.c  MZ-2000 virtual hardware
            │       ├── z80vhw_pcw.c     PCW-8256 virtual hardware
            │       ├── z80vhw_rfs.c     ROM Filing System virtual device
            │       └── z80vhw_tzpu.c    tranZPUter SW virtual hardware (K64F stub)
            ├── ttymz/
            │   ├── Makefile
            │   └── ttymzdrv.c           MZ keyboard/display TTY driver
            └── utils/
                ├── z80ctrl.c            z80drv control utility
                ├── k64fcpu.c            K64F virtual CPU daemon
                └── sharpbiter.c         Keyboard/display arbiter daemon

Entwicklungsumgebung einrichten

Die FusionX-Build-Umgebung erfordert drei separate Toolchains: einen ARM-Cross-Compiler fuer die User-Space-Dienstprogramme und Kernelmodule, das SigmaStar SDK fuer den Kernel-Header-Zugriff und Altera Quartus II fuer die CPLD-Synthese. Diese koennen alle auf einem Standard-x86-64-Linux-Host (Debian 12 / Ubuntu 22.04 LTS oder neuer empfohlen) installiert werden. Eine Java-Runtime wird ebenfalls fuer den GLASS Z80-Assembler benoetigt.

Automatisierte Einrichtung und Build (empfohlen)

Alles, was die manuellen Schritte unten von Hand installieren — der ARM-Cross-Compiler, die Java-Laufzeitumgebung fuer den GLASS-Assembler, die Kernel-Build-Abhaengigkeiten und die Quartus II-Werkzeugkette — wird automatisch durch das mitgelieferte Setup-Skript fuer Ihre Plattform installiert und gesteuert. Jedes Skript ist eigenstaendig: kopieren Sie die eine Datei fuer Ihre Plattform und fuehren Sie sie aus. Es installiert die Voraussetzungen, klont das Repository mit seinen Submodulen (standardmaessig ~/FusionX), laedt das SharpSoft-Content-Bundle herunter (TZFS_Files.zip, ~110 MB), bereitet die Werkzeugkette vor und bietet an, den ersten Build auszufuehren. Verwenden Sie es fuer eine funktionierende Umgebung in einem Schritt; die detaillierten manuellen Anweisungen, die folgen, bleiben die Referenz fuer benutzerdefinierte Einrichtungen, das Verstaendnis der einzelnen Werkzeuge und CI.
Script Platform Notes
setup_FusionX.sh Linux (native) / macOS (Docker) On Linux offers a native tool chain (Java JRE + the Linaro gcc-linaro-5.5.0-2017.10-arm-linux-gnueabihf cross toolchain to /opt/arm-linux-gnueabihf + kernel build deps) or reproducible Docker images (fusionx-build:latest, fusionx-quartus:13.0.1); on macOS uses Docker. The CPLD always builds via the Quartus Docker image (MAX7000AE).
setup_FusionX_windows.cmd Windows 10/11 Double-click launcher for the native PowerShell setup. No Docker, no WSL2.
setup_FusionX_windows_native.ps1 Windows 10/11 (native, no WSL2) winget-installs Git for Windows + Temurin 17 JRE; locates an existing Quartus II 13.x (MAX7000AE — not auto-installed, warns if absent); sets up a WSL1 distro (default Ubuntu) for the Linux-only components.
setup_FusionX_wsl1.sh WSL1 / Ubuntu (called by the Windows script) Provisions the WSL1 distro: build deps, image extras, 32-bit libs, python2 for the SigmaStar SDK, and the Linaro ARM toolchain; writes /etc/profile.d/fusionx.sh (CROSS_COMPILE=arm-linux-gnueabihf-, ARCH=arm).
Linux / macOS:
chmod +x setup_FusionX.sh
./setup_FusionX.sh
Windows 10/11 — doppelklicken Sie setup_FusionX_windows.cmd, oder aus PowerShell:
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
.\setup_FusionX_windows_native.ps1
Der Build wird von build.sh gesteuert, das pro Komponente je nach Host eine native Werkzeugkette, ein Docker-Image oder eine WSL1-Distribution auswaehlt (Linux: alles nativ; macOS: alles Docker; Windows: native ROMs/CPLD + WSL1 fuer die Linux-only-Teile). Fuehren Sie es ohne Argumente aus, um alles zu bauen, oder uebergeben Sie ein Flag fuer eine einzelne Komponente:
build.sh flag Builds Output
--asm --tzfs --cpm Z80 ROMs / TZFS / CP/M (Java + GLASS glass-0.5.1.jar) software/roms/*.bin (incl. cpm223_*.bin)
--drivers z80drv / ttymz kernel modules + apps arm-linux-gnueabihf objects
--spi SPI tools mspi_main
--cpld CPLD bit streams (MZ80A/MZ700/MZ2000/PCW8256) .pof under CPLD/v1.0/<machine>/build/output_files/
--image full SigmaStar SSD202 Linux SD image (u-boot + kernel 4.9 + Buildroot) image under software/linux/.../images
(none) / --all everything
./build.sh                 # all components
./build.sh --cpld          # just the CPLD bit streams
./build.sh --help          # list all options
Praktische Umgebungsvariablen-Ueberschreibungen (alle optional):
Variable Purpose
FUSIONX_REPO_URL Repository to clone (default https://git.eaw.app/eaw/tzpuFusionX.git).
FUSIONX_METHOD Force one build method for all components: native, docker or wsl.
FUSIONX_FILES_URL SharpSoft content bundle URL (default the shared TZFS_Files.zip).
FUSIONX_TOOLCHAIN_URL / FUSIONX_TOOLCHAIN_DIR Linaro ARM toolchain download URL / install directory (default /opt/arm-linux-gnueabihf).
FUSIONX_DIR Build in an existing checkout instead of cloning.
FUSIONX_WSL_DISTRO WSL1 distro name (default Ubuntu).
FUSIONX_ASSUME_YES Accept all prompts non-interactively (used by the Windows launcher).
Ziehen Sie es vor, die Werkzeugkette selbst zu installieren, oder benoetigen Sie eine benutzerdefinierte oder CI-Konfiguration? Die manuellen Schritte unten installieren genau das, was die Skripte automatisieren.

Voraussetzungen

Installieren Sie die Basis-Build-Tools auf Ihrem x86-64-Linux-Host:
sudo apt update
sudo apt install -y make bc libssl-dev git default-jre docker.io u-boot-tools
Fuegen Sie Ihren Benutzer der docker-Gruppe hinzu, damit Sie Docker-Container ohne sudo ausfuehren koennen:
sudo usermod -aG docker $USER
# Abmelden und erneut anmelden, damit die Gruppenaenderung wirksam wird

ARM-Cross-Compiler (Linaro GCC 5.5)

Die FusionX-Kernelmodule und User-Space-Dienstprogramme muessen mit Linaro GCC 5.5 kompiliert werden, der mit der Toolchain uebereinstimmt, die zum Erstellen des SigmaStar Linux 4.9-rt Kernels verwendet wurde. Das Standard-Distributions-Paket arm-linux-gnueabihf-gcc ist eine neuere GCC-Version und sollte nicht verwendet werden — ABI-Unterschiede zwischen GCC-Versionen koennen subtile Laufzeitfehler in Kernelmodulen verursachen.
# Linaro GCC 5.5-2017.10 fuer ARM Hard-Float herunterladen
wget https://releases.linaro.org/components/toolchain/binaries/5.5-2017.10/arm-linux-gnueabihf/gcc-linaro-5.5.0-2017.10-x86_64_arm-linux-gnueabihf.tar.xz

# Nach /opt extrahieren (erfordert Root-Rechte)
sudo mkdir -p /opt/arm-linux-gnueabihf
sudo tar xJf gcc-linaro-5.5.0-2017.10-x86_64_arm-linux-gnueabihf.tar.xz \
    -C /opt/arm-linux-gnueabihf --strip-components=1

# Zum PATH hinzufuegen (fuer Persistenz in ~/.bashrc hinzufuegen)
export PATH="/opt/arm-linux-gnueabihf/bin:$PATH"

# Ueberpruefen
arm-linux-gnueabihf-gcc --version
# Erwartete Ausgabe: arm-linux-gnueabihf-gcc (Linaro GCC 5.5-2017.10) 5.5.0
Die Toolchain belegt etwa 613 MB auf der Festplatte. Die wichtigsten Binaerdateien sind arm-linux-gnueabihf-gcc, arm-linux-gnueabihf-g++ und arm-linux-gnueabihf-ld. Das build.sh-Skript und alle Makefiles erwarten, dass diese auf dem PATH ohne absoluten Pfadpraefix verfuegbar sind.

Quartus II Docker-Images (CPLD-Builds)

Die CPLD-Bitstreams werden mit Altera Quartus II 13.0.1 SP1 Web Edition kompiliert, die letzte Version, die die auf der FusionX-Platine verwendete MAX7000AE CPLD-Familie unterstuetzt. Anstatt Quartus II nativ zu installieren (es erfordert Ubuntu 16.04 32-Bit-Bibliotheken), wird empfohlen, ein Docker-Image zu erstellen, das die gesamte Quartus II-Installation kapselt. Dieses Image kann sowohl fuer interaktive GUI-Sitzungen als auch fuer headless CI/CD-Kompilierung verwendet werden.
Erstellen des Quartus II 13.0.1 Docker-Images:
# Erstellen Sie ein Build-Verzeichnis mit dem Dockerfile und unterstuetzenden Dateien
mkdir -p quartus-docker/files
cd quartus-docker

# Erstellen Sie das Dockerfile (siehe unten) als Dockerfile.13.0.1
# Legen Sie die folgenden Dateien im files/-Unterverzeichnis ab:
#   license.dat              - Quartus license file (dummy for Web Edition)
#   quartus2.ini             - Quartus configuration
#   quartus2.qreg            - Quartus registry settings
#   quartus_web_rules_file.txt - Web edition rules
#   libjtag_hw_arrow.so      - Arrow USB Blaster library (optional, for programming)
#   70-usb.rules             - USB Blaster udev rules (optional)

# Image erstellen (laedt ~4GB an Quartus-Installationsdateien waehrend des Builds herunter)
docker build -f Dockerfile.13.0.1 \
    --build-arg user_uid=$(id -u) \
    --build-arg user_gid=$(id -g) \
    --build-arg user_name=$(whoami) \
    -t quartus-ii-13.0.1 .
Das Dockerfile basiert auf Ubuntu 16.04 (Xenial) und laedt den Quartus II 13.0.1 SP1 Web Edition Installer, Programmer, Hilfedateien und Device Support Packages (MAX, Cyclone, Arria) direkt von den Altera-Download-Servern waehrend des Builds herunter. Das resultierende Docker-Image ist etwa 15-20 GB gross.
Vollstaendige Dockerfile- und Kompilierungsdetails finden Sie in der englischsprachigen Dokumentation, da der gesamte Dockerfile-Inhalt, Docker-Befehle und Konfigurationscode unveraendert bleiben.

Toolchain-Uebersicht

Komponente Werkzeug Version Installation
Z80 assembler GLASS 0.5.1 Bundled in software/tools/glass-0.5.1.jar (requires Java)
ARM cross-compiler Linaro GCC 5.5.0 Manual install to /opt/arm-linux-gnueabihf/
Kernel modules make + kbuild Linux 4.9-rt Kernel source included in repository
SPI tools arm-linux-gnueabihf-gcc 5.5.0 Same Linaro toolchain as above
CPLD bitstreams Quartus II 13.0.1 SP1 Docker image (see above)
Linux SD image Build_FusionX.sh Full kernel tree + ARM toolchain
Build orchestration build.sh Repository root

Klonen und Erstellen

# Repository klonen (enthaelt den vollstaendigen Kernel-Baum — etwa 1,5 GB)
git clone https://git.eaw.app/eaw/tzpuFusionX.git
cd tzpuFusionX

# Git-Submodule initialisieren (Z80- und 6502-CPU-Emulator-Bibliotheken)
git submodule update --init --recursive

# Alles erstellen (Z80-ROMs, TZFS, CP/M, Kernelmodule, SPI-Tools, CPLD-Bitstreams)
./build.sh --all

# Oder einzelne Komponenten erstellen:
./build.sh --asm           # Z80-Assembly-ROMs und MZF-Dateien
./build.sh --tzfs          # TZFS-ROMs fuer MZ-80A/700/2000
./build.sh --cpm           # CP/M 2.2 Binaerdateien
./build.sh --drivers       # Kernelmodule (z80drv, ttymzdrv) und User-Space-Anwendungen
./build.sh --spi           # SPI-Tools (mspi_main)
./build.sh --cpld          # CPLD-Bitstreams (erfordert Quartus Docker-Image)
./build.sh --image         # Linux SD-Karten-Image (erfordert vollstaendigen Kernel-Baum)
./build.sh --clean         # Alle Build-Artefakte entfernen
Das build.sh-Skript erkennt automatisch verfuegbare Werkzeuge und ueberspringt Build-Stufen, wenn Voraussetzungen nicht erfuellt sind. Wenn beispielsweise der ARM-Cross-Compiler nicht im PATH ist, werden Treiber- und SPI-Builds mit einer Meldung uebersprungen. Wenn das Quartus Docker-Image nicht verfuegbar ist, werden CPLD-Builds uebersprungen. Dies ermoeglicht partielle Builds auf Maschinen, die nur eine Teilmenge der Toolchains installiert haben.
Der Build erzeugt die folgenden Ausgaben:
Ausgabe Ort Inhalt
Monitor ROMs software/roms/*.rom SA-1510, 1Z-013A, Kuma, MZ-2000/800 IPL ROMs
MZF files software/roms/*.mzf MS BASIC, SA-5510, test programs
TZFS ROMs software/roms/tzfs_*.rom TZFS firmware for each target machine
CP/M binaries software/roms/cpm223_*.bin CP/M 2.2 with CBIOS for each target
Kernel modules software/FusionX/modules/*.ko z80drv.ko, ttymzdrv.ko (last built target)
User-space apps software/FusionX/bin/ z80ctrl, k64fcpu, sharpbiter
SPI tools software/FusionX/src/spitools/mspi_main SPI diagnostic utility
CPLD bitstreams CPLD/v1.0/*/build/output_files/*.pof One .pof per target machine
Linux SD image software/linux/project/image/output/images/ sdrootfs.tar.gz, SigmastarUpgrade*.bin

Fuer die vollstaendigen Details zu SDK-Setup, Kernelmodul-Build, Continuous Integration (Jenkins), Datenstrukturen, Dispatch-Schleife, Hinzufuegen neuer Maschinen, Hinzufuegen virtueller Hardware-Geraete, Aendern des CPLD, Cross-Kompilierung von Benutzerprogrammen, OTA-Firmware-Update und haeufigen Fallstricken — einschliesslich vollstaendiger Code-Beispiele, Jenkins-Pipeline-Skripte und Dockerfile-Inhalte — beziehen Sie sich bitte auf die englischsprachige Dokumentation, da der gesamte Code, die Befehle und die technische Konfiguration unveraendert bleiben.


Wichtige Datenstrukturen

Die in z80driver.h definierten Datenstrukturen bilden das Rueckgrat der Emulation. Ihr Verstaendnis ist wesentlich, bevor der Treiber modifiziert oder ein neues Maschinenziel hinzugefuegt wird.

Speicherabbildung

Jede unterstuetzte Maschine hat einen Satz von Praeprozessor-Konstanten, die ihre Speicherbereiche definieren, gefolgt von einer Tabelle von t_memRegion-Strukturen, die die Dispatch-Schleife zur Laufzeit verwendet. Die Konstanten sind durch das entsprechende TARGET_*-Define geschuetzt, das vom Varianten-Makefile gesetzt wird.
// z80driver.h — MZ-80A memory map example
#define MZ80A_MONITOR_ROM_ADDR    0x0000
#define MZ80A_MONITOR_ROM_SIZE    0x1000  // 4KB system monitor
#define MZ80A_VRAM_ADDR           0xD000  // Video RAM start
#define MZ80A_VRAM_SIZE           0x0800  // 2KB VRAM
#define MZ80A_IO_KEYBOARD         0xE000  // Keyboard I/O port

typedef struct {
    uint32_t  baseAddr;       // Z80 address space start
    uint32_t  size;           // Region size in bytes
    uint8_t  *data;           // Pointer to emulated memory buffer
    uint8_t   type;           // MEM_ROM, MEM_RAM, MEM_VHARDWARE, MEM_PHYSICAL
    void     (*read_fn)(uint16_t addr, uint8_t *data);   // Virtual hardware read handler
    void     (*write_fn)(uint16_t addr, uint8_t data);   // Virtual hardware write handler
} t_memRegion;
Das type-Feld steuert das Dispatch-Verhalten: MEM_ROM-Bereiche geben Daten aus dem Puffer zurueck und ignorieren Schreibvorgaenge stillschweigend; MEM_RAM-Bereiche erlauben sowohl Lesen als auch Schreiben in den Puffer; MEM_VHARDWARE-Bereiche rufen die read_fn/write_fn-Handler auf, anstatt den Puffer zu beruehren; MEM_PHYSICAL-Bereiche leiten den Zyklus an die reale Hardware auf dem Host-Maschinenbus weiter.

Buszyklus-Anforderung

Wenn das CPLD einen ausstehenden Buszyklus ueber GPIO signalisiert, liest die HAL-Schicht die Adress- und Steuerleitungen und befuellt eine t_busCycle-Struktur. Diese Struktur wird dann in die Dispatch-Schleife zur Weiterleitung uebergeben.
// Bus cycle information captured from CPLD GPIO pins
typedef struct {
    uint16_t  address;        // Z80 address bus A0-A15
    uint8_t   data;           // Z80 data bus D0-D7
    uint8_t   busType;        // BUS_MREQ_RD, BUS_MREQ_WR, BUS_IORQ_RD, BUS_IORQ_WR, BUS_M1
    bool      isRead;         // true = read cycle, false = write cycle
} t_busCycle;

Virtual Hardware Module-Schnittstelle

Jede z80vhw_*.c-Datei implementiert einen festen Satz von Funktionen. Die Dispatch-Schleife ruft diese Funktionen auf, wenn ein Buszyklus einen als MEM_VHARDWARE registrierten Bereich anspricht. Die Schnittstellenfunktionen muessen alle in jedem Virtual Hardware Module vorhanden sein, auch wenn einige fuer eine bestimmte Maschine No-Ops sind.
// Each z80vhw_*.c implements these functions:

// Called once at module load — register memory/IO regions and handlers
int vhw_init(void);

// Memory read handler — called by dispatch loop for memory-mapped regions
uint8_t vhw_mem_read(uint16_t addr);

// Memory write handler
void vhw_mem_write(uint16_t addr, uint8_t data);

// I/O read handler (not used for 6502-based machines, always present for Z80)
uint8_t vhw_io_read(uint16_t port);

// I/O write handler
void vhw_io_write(uint16_t port, uint8_t data);

// Called on Z80 RESET — reinitialise hardware state
void vhw_reset(void);

// Called periodically from dispatch loop — for timers, sound emulation, etc.
void vhw_tick(uint64_t cycles);
Die vhw_init()-Funktion ist dafuer verantwortlich, register_mem_region() und register_io_handler() aufzurufen, um der Dispatch-Schleife mitzuteilen, welche Adressbereiche dieses Modul verarbeitet. Registrierungen, die in vhw_init() vorgenommen werden, bestehen fuer die gesamte Lebensdauer des Kernelmoduls.

z80driver.c — Dispatch-Schleife

Die Dispatch-Schleife ist der Hotpath des gesamten FusionX-Systems. Sie laeuft als Kernel-Thread, der an CPU1 gebunden ist (isoliert ueber isolcpus=1 in den Kernel-Boot-Argumenten), was verhindert, dass der Linux-Scheduler sie waehrend Z80-Buszyklen verdraengt. Jeder Z80-Maschinenzyklus, den das CPLD abfaengt, muss von dieser Schleife innerhalb der Z80-Haltezeit bedient werden, die bei 4 MHz etwa 250 ns betraegt.
Bei jeder Iteration fuehrt die Schleife die folgenden Schritte durch: Sie liest die CPLD GPIO-Leitungen, um den ausstehenden Buszyklus (Adresse und Zyklustyp) zu erhalten; sucht die Adresse in der registrierten Speicherbereichstabelle; und dispatcht an den entsprechenden Handler — gibt ROM-Daten zurueck, greift auf den Kernel-RAM-Puffer zu, ruft einen Virtual Hardware Handler auf oder ruft die Zeta Z80-Bibliothek fuer Opcode-Fetch-Zyklen auf. Fuer Lesezyklen wird das Antwortbyte ueber SPI an das CPLD zurueckgeschrieben. Periodische Wartungsarbeiten (Aufruf von vhw_tick()) werden alle 2048 Iterationen durchgefuehrt.
// Simplified dispatch loop (z80driver.c)
static int z80_emulation_thread(void *data)
{
    while (!kthread_should_stop()) {
        // 1. Wait for CPLD to signal pending bus cycle (GPIO IRQ or poll)
        t_busCycle cycle = cpld_read_bus_cycle();    // reads GPIO pins

        // 2. Dispatch based on cycle type and address
        if (cycle.busType == BUS_M1) {
            // Opcode fetch — run one Z80 instruction via Zeta library
            zeta_run_one_instruction(&z80_state);

        } else if (cycle.busType == BUS_MREQ_RD) {
            // Memory read
            uint8_t data = dispatch_mem_read(cycle.address);
            cpld_write_data(data);                   // SPI write to CPLD

        } else if (cycle.busType == BUS_MREQ_WR) {
            // Memory write
            dispatch_mem_write(cycle.address, cycle.data);

        } else if (cycle.busType == BUS_IORQ_RD) {
            // I/O read
            uint8_t data = dispatch_io_read(cycle.address & 0xFF);
            cpld_write_data(data);

        } else if (cycle.busType == BUS_IORQ_WR) {
            // I/O write
            dispatch_io_write(cycle.address & 0xFF, cycle.data);
        }

        // 3. Periodic housekeeping
        if ((cycle_count++ & 0x7FF) == 0)
            vhw_tick(cycle_count);
    }
    return 0;
}
Die dispatch_mem_read()- und dispatch_mem_write()-Funktionen fuehren eine lineare Suche in der registrierten t_memRegion-Tabelle durch, um den Bereich zu finden, der die angeforderte Adresse abdeckt. Fuer die Leistung sollte die Tabelle so geordnet sein, dass die am haeufigsten abgerufenen Bereiche zuerst kommen (typischerweise RAM, dann ROM, dann virtuelle Hardware). Eine zukuenftige Optimierung koennte die lineare Suche durch eine 256-Eintrags-Nachschlagetabelle ersetzen, die durch die oberen 8 Bits der Adresse indiziert wird.

Eine neue Maschine hinzufuegen

Das Hinzufuegen von Unterstuetzung fuer eine neue Host-Maschine ist die haeufigste Entwickleraufgabe. Der Prozess umfasst fuenf diskrete Schritte, die alle drei Schichten des Software-Stacks umfassen. Fuer die detaillierten Code-Beispiele (einschliesslich Speicherabbildungsdefinitionen, Virtual Hardware Module-Skelett, Build-Varianten-Verzeichnis-Setup, CPLD VHDL-Variante und Startskript) beziehen Sie sich bitte auf die englischsprachige Dokumentation, da alle Code-Beispiele unveraendert bleiben.

Referenz-Websites

Ressource Link
tranZPUter FusionX project page /tranzputer-fusionx/
tranZPUter FusionX User Manual /tranzputer-fusionx-usermanual/
tranZPUter FusionX Technical Guide /tranzputer-fusionx-technicalguide/
SigmaStar SSD202 Product Page sigmastar.com.tw
Altera MAX7000AE Device Family Datasheet intel.com
Zeta Z80 Emulator Library github.com/redcode/Zeta
Quartus II 13.0.1 SP1 Web Edition intel.com legacy software
Linux PREEMPT_RT Patch wiki.linuxfoundation.org/realtime
Buildroot Project buildroot.org
arm-linux-gnueabihf Toolchain packages.ubuntu.com/gcc-arm-linux-gnueabihf

Hinweis zur Funkregulierung

Dieses Geraet enthaelt einen SSW101B 2,4 GHz IEEE 802.11 b/g/n Funktransceiver (integriert im SigmaStar SSD202 SOM), der es zu einem absichtlichen Sender im Sinne der Funkfrequenzvorschriften weltweit macht (einschliesslich FCC Part 15 Subpart C in den Vereinigten Staaten und der Funkanlagenrichtlinie 2014/53/EU in der Europaeischen Union).
Obwohl das SOM-Modul bestehende regulatorische Zertifizierungen traegt, erstrecken sich diese modulbezogenen Zertifizierungen nicht automatisch auf ein fertiges Produkt, das das Modul enthaelt. Die Ausnahme fuer vorzertifizierte Module erlaubt einzelnen Bastlern, eine begrenzte Anzahl von Geraeten fuer persoenlichen, experimentellen oder bildungsbezogenen Gebrauch zu bauen, ohne eine separate Geraetezulassung zu erhalten.
Wichtige Einschraenkungen
  • Zusammengebaute Geraete duerfen nicht verkauft, zum Verkauf angeboten, verschenkt oder anderweitig an Dritte verteilt werden, es sei denn, das fertige Produkt wurde unabhaengig getestet und hat eine eigene Geraetezulassung (z.B. FCC ID, CE-Kennzeichnung mit Bewertung durch eine benannte Stelle) in der entsprechenden Rechtshoheit erhalten.
  • Der Bau dieses Projekts fuer den persoenlichen Gebrauch in begrenzter Stueckzahl ist im Allgemeinen unter Hobby- und Experimentierbestimmungen zulaessig (z.B. FCC § 15.23), vorausgesetzt, das Geraet verursacht keine schaedlichen Stoerungen.
  • Regulatorische Anforderungen variieren je nach Land. Erbauer ausserhalb der Vereinigten Staaten sollten ihre nationale Funkfrequenzbehoerde bezueglich der geltenden Regeln konsultieren.
Verantwortung des Erbauers
Es liegt in der alleinigen Verantwortung des Erbauers sicherzustellen, dass jedes aus diesen Designs konstruierte Geraet allen geltenden Funkfrequenzvorschriften in seiner Rechtshoheit entspricht. Der Autor stellt diese Designs fuer den persoenlichen, bildungsbezogenen und hobbymässigen Gebrauch zur Verfuegung und gibt keine Zusicherung, dass ein aus ihnen gebautes Geraet die regulatorischen Anforderungen fuer die kommerzielle Verteilung erfuellt.