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.
- Linux-Kernelmodule (
z80drv.ko,ttymzdrv.ko) — in C geschrieben, gegen den SigmaStar Linux 4.9-rt Kernel-Baum gebaut.z80drvfuehrt die Z80-Emulations-Dispatch-Schleife auf einem isolierten CPU-Kern aus und kommuniziert mit dem CPLD ueber SPI und GPIO.ttymzdrvbietet eine TTY-Schnittstelle zur Sharp MZ Tastatur- und Zeichenanzeige-Hardware. - User-Space-Dienstprogramme (
z80ctrl,k64fcpu,sharpbiter) — in C geschrieben, Cross-kompiliert mitarm-linux-gnueabihf-gcc. Diese Dienstprogramme starten, stoppen und konfigurieren das Kernelmodul zur Laufzeit;k64fcpuagiert als Daemon, der die K64F virtuelle CPU-Schnittstelle emuliert;sharpbitervermittelt den Zugriff auf Tastatur und Display zwischen der Host-Maschinen-Software und der Linux-Konsole. - 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
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.
- 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.
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.