tranZPUter^FusionX

Der tranZPUter^FusionX ist ein Ablegerkonzept der tranZPUter-Serie. Er dient dem gleichen Zweck: den physischen Z80 in einem Sharp- oder aehnlichen System zu ersetzen und ihm Funktionen wie eine schnellere CPU, mehr Speicher, virtuelle Geraete, schnelles Laden von Anwendungen von der SD-Karte zu bieten, und durch Verwendung einer Tochterplatine bessere Grafik und besseren Sound bereitzustellen. Die FusionX-Platine kann auch verwendet werden, um alternative CPUs auf dem Host fuer Tests, Entwicklung und eine voellig andere Softwareplattform und Anwendungen bereitzustellen. Sie kann die Tastatur, den Monitor und die E/A des zugrunde liegenden Hosts nutzen und zusaetzlich bessere Grafik und besseren Sound, die vom FusionX bereitgestellt werden. Sie weist Aehnlichkeiten mit dem tranZPUter^Fusion auf, realisiert das Konzept jedoch in Software als Anwendung statt in Hardware ueber ein FPGA. Dies wird durch ein SOM (System On a Module) ermoeglicht, das nicht viel groesser als ein FPGA-Baustein ist und dennoch eine Fuelle von Funktionen bietet: Dual-Core 1,2 GHz Cortex-A7 ARM CPU, 128 MB RAM, 256 MB FlashRAM, WLAN, HD-Video, SD-Karte, USB-Anschluss und das Linux-Betriebssystem. Unter Verwendung des gleichen Basisdesigns wie der tranZPUter^Fusion enthaelt er ein CPLD zur Anbindung des Z80-Hosts an das SOM und zur Bereitstellung zyklusgenauer Z80-Zeitsteuerung. Das SOM ist ueber einen 72 MHz SPI-Kanal und einen 8-Bit-Bus mit dem CPLD verbunden, um den Signalstatus abzufragen und Z80-Transaktionen einzuleiten. In der Z80-Konfiguration instanziiert ein Linux-Kerneltreiber eine Z80-Emulation, die eine Z80-CPU in Software realisiert und dadurch das Hostsystem steuern und kontrollieren kann. Der Kerneltreiber zusammen mit einer steuernden Anwendung kann dem Host ueber diesen Mechanismus eine Vielzahl von Funktionen bereitstellen. Das SOM ist auch mit einem SD-Laufwerk und einem USB 2.0-Anschluss verbunden, sodass den bereitstellbaren Funktionen keine Grenzen gesetzt sind. Wie der tranZPUter^Fusion kann der tranZPUter^FusionX erweiterte Video- und Soundfunktionen fuer den Host bereitstellen. Das SOM verfuegt ueber duales DAC-Audio und eine 2D-GPU mit konfigurierbaren Aufloesungen, die unter Softwaresteuerung auf die Video- und Audioausgaenge des Hosts geschaltet werden. Die FusionX-Platine ist ideal fuer jeden Entwickler, der physisch mit Retro-Hardware programmieren und interagieren moechte, unter Verwendung einer Linux-Plattform mit WLAN- und USB/Seriell-Konnektivitaet. Fuer die meisten Retro-Nutzer wird die Platine in den fruehen Stadien der FusionX-Entwicklung wenig Nutzen haben. Wenn das Projekt reift, kann eine Platine erworben und in den Z80-Sockel ihres Sharp- oder aehnlichen Z80-basierten Systems eingebaut werden (sofern ausreichend Platz vorhanden ist) und die erweiterten Funktionen genutzt werden, wie:

• Originale Host-Spezifikationen
  - die Maschine verhaelt sich so, als waere ein physischer Z80 eingebaut. Es kann geringfuegige Unterschiede in der Z80-Funktionalitaet geben, da sie in Software implementiert ist, aber das Z80-Hardware-Timing ist genau.
• Beschleuniger
  - der Z80 kann dank des reichlichen Speichers und des 1,2 GHz Dual-Core-Prozessors mit deutlich hoeheren Geschwindigkeiten laufen, was typischerweise eine Leistung bis zu der eines 500 MHz Z80 erreichen wuerde.
• Emulation
  - Emulation aller Sharp MZ-Serienmaschinen, erlebbar ueber die Tastatur, den Monitor und die E/A des Hostsystems.
• Grafik
  - alle originalen Sharp MZ-Grafikmodi, unabhaengig vom Host, einschliesslich zusaetzlicher Aufloesungen bis HD, sind ueber die GPU-Konfiguration verfuegbar und koennen auf dem Host in Sprachen wie Basic ausgewaehlt und programmiert werden.
• Sound
  - der Host hat Zugang zu den Stereo-DAC-Wandlern, die 48 KHz CD-Qualitaetssound wiedergeben oder den SN76489 oder den einfachen Bit/Timer-Sound der Sharp-Serie emulieren koennen. Tonaufnahme ist auch ueber den Mikrofon-Eingang moeglich.
• Prozessoren
  - es gibt viele Software-CPU-Implementierungen, die auf diese Plattform portiert werden koennen, zum Beispiel die ARM-Plattform-CPU-Emulationen des BBC PiCoPro. Dies ermoeglicht potenziell den Betrieb anderer Maschinen, wie z.B. des BBC, auf diesem Sharp-Host, unter Nutzung der erweiterten Grafik und des Sounds des SOM.
• Linux
  - unter Verwendung der Host-Tastatur, des Lautsprechers, des Monitors usw. kann eine vollwertige Linux-Version, einschliesslich WLAN, an der Host-Konsole genutzt werden.

Version 1.0 ist die erste offizielle Veroeffentlichung des tranZPUter^FusionX-Designs. Die FusionX-Platine baut auf einer bewaehrten Z80-Host-Schnittstelle auf, die das Altera 7000A MAX CPLD-Bauelement verwendet. Das CPLD stellt nicht nur die Verbindung zwischen den 5V-Z80-Host-Signalen und den 3,3V-Signalen neuerer Bauelemente her, sondern bettet auch die Logik ein, um genaues Z80-Timing mittels eines 50 MHz-Taktes zu realisieren, der den Z80-Host-Takt abtastet und Signale gemaess den veroeffentlichten Z80-Zustandsdiagrammen aktiviert. Zusaetzlich enthaelt der FusionX ein SigmaStar System-On-a-Module, ein kleines 29mm x 29mm Stamp-Bauelement, das eine Dual-Core Cortex-A7 CPU, 128 MByte DRAM, 256 MByte FlashNAND und einen WLAN-Transceiver integriert. Das SigmaStar SOM kann 2D-Grafik im RGB 888-Format mit waehlbarer Aufloesung bis zum HD-Format ausgeben. Es ist auch zu Stereo-Audio-DAC-Ausgabe bei 48 KHz faehig. Klicken Sie hier, um die vollstaendige SigmaStar Produktuebersicht anzuzeigen. Unter Nutzung der auf dem tranZPUter SW-700 gesammelten Erfahrung wird ein 30-Bit Video-DAC gewaehlt, um das SigmaStar SOM-Video anstelle einer 2R-R-Leiter zu rendern, und zusaetzlich ist ein 8-Bit-DAC zur Darstellung von Monochrom-Monitor-Kontraststufen enthalten, um Farbschattierungen auf monochromen CRT-Monitoren, wie sie im MZ-80A/MZ-2000 zu finden sind, zu beruecksichtigen. Das Hardware-Design basiert auf einer Hauptplatine, die alle primaeren Schaltkreise enthaelt, und einer Reihe von Tochterplatinen, wobei jede Tochterplatine einem bestimmten Host gewidmet ist (d.h. MZ-700, MZ-80A, MZ-2000). Die Tochterplatine faengt das Video-/Audiosubsystem des Hosts ab und unterstuetzt das Umschalten des Host-Video/Audio und des Hauptplatinen-Video/Audio auf den Monitor/Lautsprecher des Hosts. Die Hauptplatine kann ohne Tochterplatinen verwendet werden; letztere werden nur benoetigt, wenn SOM-Video/Audio erforderlich ist. Dieser Abschnitt beschreibt die Schaltplaene und das Platinendesign der Hauptplatine des tranZPUter^FusionX.

Der Schaltplan verbindet den Z80 mit dem CPLD. Das CPLD ist 5V-tolerant und arbeitet intern mit 3,3V. Die Ausgaenge sind als Low Voltage TTL ausgewaehlt, was bedeutet, dass eine '1' durch 3,3V repraesentiert wird, im Gegensatz zu 5V im Hostsystem. Die Spezifikationen von 5V TTL sehen die Schaltschwelle bei ca. 2,4V, somit kann das CPLD 5V-Schaltkreise ansteuern und mit ausreichendem Treiberstrom, 25 mA pro Pin. Die internen CPLD-Zustandsmaschinen werden von einem externen 50 MHz-Oszillator getaktet, was eine angemessene Abtastung und Zustandsaenderung fuer einen typischen 1 MHz - 6 MHz Z80-Host ermoeglicht.

Das SOM ist reich an Peripheriegeraeten und diese Schaltung verbindet einige davon fuer die Verwendung im FusionX, darunter:

• Stereo-Audio-Mikrofoneingang
  - ein digitaler Mikrofoneingang ist ebenfalls verfuegbar, aber die Pins werden in der CPLD-Schnittstelle verwendet.
• Stereo-Audio-DAC-Ausgang
  - duale Digital-Analog-Wandler fuer die Tonausgabe, die mit 48 KHz getaktet werden koennen.
• WLAN-Antenne
  - ein SSW101B 20/40 MHz IEEE 802.11 b/g/n/e/l/n/w WLAN-Transceiver, der im 2,4 GHz-Band mit einer Reichweite von 500 m arbeitet. Das SOM enthaelt auch einen 100 MHz ETH PHY, der in diesem Design jedoch nicht verwendet wird, da kabelgebundenes Ethernet fuer eine Platine, die in einer Retro-Maschine eingebaut ist, nicht praktikabel ist.
• USB Serial
  - unter Linux wird die Konsole auf einem UART-Seriengeraet praesentiert. Dieses Seriengeraet wird zur einfachen Nutzung in USB umgewandelt, um die Linux-Konsole anzuzeigen und mit ihr zu interagieren.
• USB
  - ein Linux-verbundener USB-Anschluss zur Geraeteerweiterung, z.B. zusaetzlicher Speicher, Maeuse usw.
• Fast UART
  - Hochgeschwindigkeits-Vollduplex mit Hardware-Handshake UART.
• UART
  - Standard 2-Pin UART mit bis zu 500 KHz Betrieb.
• SD-Karte
  - das SOM hat eingebautes FlashNAND und kann daher ein einfaches Linux-Dateisystem aufnehmen; der Zusatz einer SD-Karte ermoeglicht groesseren Speicher fuer Host-Anwendungen und Linux-Dienstprogramme. Eine SD-Karte erleichtert auch Upgrades, da das SOM beim Booten mit einer entsprechend vorbereiteten SD-Karte automatisch aktualisiert.

Das SOM gibt TTL RGB mit 8 Bit pro Farbe aus. Dies wird mit einem 30-Bit VideoDAC verbunden, wobei die niedrigsten 2 Bits pro Farbe vom CPLD gesteuert werden. Zusaetzlich wird, um die internen Monochrom-Monitore des Sharp MZ-80A/MZ-80B/MZ-2000 anzusteuern, ein 8-Bit VideoDAC hinzugefuegt, der ein Videosignal im Bereich von 4V-5V unter Verwendung eines 332 RGB-Farbeingangs ausgibt, wobei der Farbeingang das MSB des SOM 888 TTL-Ausgangs ist. Ich nenne dies den Kontrast-DAC, da er das Videosignal mit Farbinformationen als spannungsgesteuertes Kontrastsignal sendet, das sich auf dem Monitor als unterschiedliche Kontraststufen praesentiert und so Farbe als Graustufen simuliert. Um echtes Schwarz zu erhalten, erzeugt das CPLD ein Austastsignal, MONO.BLANK, das mit einer MUX 0V-Klammer auf der Tochterplatine gepaart wird, die den Monochrom-Monitor ansteuert. Dies sieht das RGB332 als 0V, wenn 00000000 vorliegt, und variiert dann zwischen 4,01V-5V bei Nicht-Null.

Die Stromversorgung fuer das SOM und CPLD wandelt die am Z80-Sockel vorhandenen 5V mittels eines hocheffizienten Abwaertswandlers in 3,3V um. Dies ist notwendig, um Waerme zu minimieren und dem SOM/CPLD maximalen Strom bereitzustellen. Zusaetzlich ist ein softwaregesteuerter USB-Netzschalter installiert, um die +5V-Stromversorgung des USB-Erweiterungsanschlusses zu aktivieren (und bei Bedarf zurueckzusetzen).

Der letzte Schaltplan ist die Schnittstelle zwischen dem SOM und dem CPLD. Urspruenglich sollte dies ein bidirektionaler 16-Bit-Bus mit Read/Write- und Strobe-Signalen sein, aber nach Tests war die Einrichtungszeit fuer ein 16-Bit-Signal mit Tristate-Umschaltung viel langsamer als eine SPI-Verbindung, aufgrund des GPIO-Register-Layouts und der Funktionsweise der E/A-Operationen innerhalb des SOM und der Geschwindigkeit der E/A-Operationen innerhalb des SOM. Die verwendete Loesung besteht aus einem bidirektionalen 72 MHz SPI-Bus zwischen SOM und CPLD zur Uebertragung von Z80-Transaktionsanforderungen und einem 8-Bit-Read-Only-Parallelbus zum schnelleren Lesen von Z80-Daten und separaten Z80-Zustandsinformationen.

Die Leiterplatte wurde mit minimaler Groesse als primaere Anforderung fuer die verschiedenen Maschinen entworfen, in denen sie installiert werden soll. Sie musste auch mit dem tranZPUter^Fusion fuer Austauschbarkeit kompatibel sein. Ein grosses Anliegen war die Waermeableitung, da die Leiterplatte, wenn sie in einem MZ-700 installiert ist, sehr nahe an vorhandenen Motherboard-Komponenten liegt, die viel Waerme abgeben, ohne Luftzirkulation in einem versiegelten kompakten Gehaeuse. Dies bedeutete, dass aktive Komponenten nicht auf der Unterseite der Leiterplatte platziert werden konnten, da die Waermeerzeugung zu Instabilitaet und Ausfall fuehren wuerde, was wiederum zu einer Vergroesserung der endgueltigen Leiterplattenmasse fuehrte. Die kleinsten Bauteile, die manuell bestueckt werden konnten, wurden verwendet, d.h. 0402/0603 passive Bauteile und 0,5 mm IC-Rasterabstand, um die Gesamtgroesse zu reduzieren, und ein 4-Lagen-Aufbau wurde gewaehlt, um alle erforderlichen Komponenten unterzubringen.

Klicken Sie hier, um ein interaktives PCB-Bauteilplatzierungsdiagramm und eine Stueckliste anzuzeigen.

Der tranZPUter^FusionX verwendet ein Altera MAX7000AE CPLD — konkret das EPM7512AETC144-10 — als zentrale Schnittstelle zwischen dem SOM und dem Z80-Host-Sockel. Es handelt sich um ein 512-Makrozellen-, 144-Pin-TQFP-Bauelement, das mit 3,3V LVTTL an seinen Ausgaengen arbeitet und 5V TTL-Pegel an seinen Eingaengen akzeptiert, was es direkt kompatibel mit historischer Sharp MZ- und anderer Z80-basierter Hardware macht, ohne zusaetzliche Pegelanpassung. Das CPLD-Design ist in VHDL geschrieben und mit Altera Quartus II 13.0.1 SP1 (Web Edition) erstellt. Da jede Host-Maschine leicht unterschiedliche Bustiming-Anforderungen und Speicherabbildungsbeschraenkungen hat, wird fuer jeden unterstuetzten Host eine separate VHDL-Implementierung gepflegt:

Das CPLD erfuellt mehrere Funktionen, die direkt in Software auf dem SOM unpraktisch oder unmoeglich zu implementieren waeren:

• Spannungspegelumsetzung
  — Ueberbrueckt den 5V TTL Z80-Host-Bus zu den 3,3V LVTTL-Signalen des SOM. Das MAX7000AE ist 5V-tolerant an den Eingaengen und treibt Ausgaenge mit 3,3V, was die 2,4V-Schaltschwelle von 5V TTL-Empfaengern ueberschreitet, mit bis zu 25 mA Treiberstrom pro Pin.
• Zyklusgenaues Z80-Bustiming
  — Das CPLD implementiert einen Hardware-FSM, der von einem externen 50 MHz-Oszillator getaktet wird und den Z80-Host-Takt abtastet und die praezise T-State-Sequenz fuer jeden Bus-Zyklustyp reproduziert. Dies entlastet das SOM von allem kritischen Timing, das nur innerhalb des vom CPLD-FSM definierten Zeitfensters mit Daten antworten muss.
• SOM-Schnittstellenueberbrueckung
  — Konvertiert zwischen dem Z80-Parallelbusprotokoll und der SPI + 8-Bit GPIO-Schnittstelle des SOM-Kernelmoduls und uebersetzt Busereignisse in ein Format, das der SSD202 effizient von einem Linux-Kernel-Thread bedienen kann.
• Video- und Audioumschaltung
  — Steuert Multiplexer, die zwischen dem nativen Video-/Audioausgang der Host-Maschine und dem SOM-Video/Audio zur Weiterleitung an Monitor und Lautsprecher ueber Tochterplatinen-Anschluesse auswaehlen. Die Umschaltung wird vom SOM ueber SPI gesteuert.
• Videosynchronisation und Takterzeugung
  — Erzeugt Composite Sync (VGA_CSYNCn) aus den SOM VSync- und HSync-Signalen, erkennt Austastintervalle, erzeugt einen 25 MHz Pixeltakt fuer den Monochrom-DAC (durch Teilung des 50 MHz-Oszillators) und produziert ein Farbtraegerfrequenzsignal (VGA_COLR) fuer die Composite-Farbausgabe.
• Reset-Verwaltung
  — Ueberwacht die Z80-RESET-Leitung des Hosts und implementiert ein Doppeldruck-Reset-Protokoll: Ein einzelner Resetdruck loest einen Soft-Reset an das SOM aus (der die Neuinitialisierung der Z80-Anwendung ermoeglicht), waehrend ein zweiter Druck innerhalb einer Sekunde die SOM PM_RESET-Leitung ansteuert, um einen vollstaendigen SOM-Neustart zu erzwingen.
• USB-Stromsteuerung
  — Steuert das USB VBUS Power-Enable-Signal unter SOM-Befehl.

Das Herzstuck des CPLD-Designs ist eine endliche Zustandsmaschine (SOMFSMState), die den Z80-Buszykluszustand mit 50 MHz Aufloesung verfolgt und reproduziert. Die FSM ueberwacht die Z80-Taktflanken des Hosts und die Buskontrollsignale (MREQ, IORQ, RD, WR, M1, RFSH, BUSRQ, HALT, WAIT), um jeden Buszyklus zu klassifizieren und die korrekte T-State-Sequenz zu durchlaufen:

Jeder Zustand hat nummerierte Unterzustaende (z.B. FetchCycle_11, FetchCycle_20), die einzelnen Halbzyklen innerhalb des T-State entsprechen und es dem CPLD ermoeglichen, Steuersignale mit sub-Taktzyklus-Praezision relativ zu den Host-CLK-Flanken zu aktivieren oder zu deaktivieren. Eine sekundaere CTRLFSMState FSM verarbeitet SPI-Befehle (CTRLCMD_Idle → CTRLCMD_ReadIOWrite) unabhaengig von der Hauptbuszyklus-FSM, sodass SPI-Transaktionen vom SOM die Bedienung von Z80-Buszyklen nicht blockieren.

Das CPLD bietet dem SOM zwei unterschiedliche Schnittstellen:

• SPI Slave (Schreibpfad)
  — Ein 4-Draht SPI Slave (VSOM_SPI_CLK, VSOM_SPI_MOSI, VSOM_SPI_MISO, VSOM_SPI_CSn) empfaengt Befehle und Daten vom SOM. Bis zu 4 Bytes pro Frame werden ueber ein serielles Schieberegister eingeschoben und in Buskontrollbefehle dekodiert (Memory Write Data, I/O Write Data, Video/Audio-Quellenauswahl, USB-Stromsteuerung). Die SPI-Taktpolaritaet ist parametrisiert (SPI_CLK_POLARITY), um verschiedene SOM-SPI-Konfigurationen zu unterstuetzen.
• 8-Bit Parallelbus (Lesepfad)
  — Ein 8-Bit-Ausgangsbus (VSOM_DATA_OUT[7:0]) mit einer VSOM_HBYTE-Auswahlleitung praesentiert entweder das Low- oder High-Byte des aktuellen Z80-Adress/Datenworts an die SOM-GPIO-Eingaenge. Zusaetzliche Einzel-Bit-Statusleitungen melden: VSOM_READY (FSM inaktiv), VSOM_LTSTATE (letzter T-State des aktuellen Zyklus), VSOM_BUSRQ, VSOM_BUSACK, VSOM_INT, VSOM_NMI, VSOM_WAIT und VSOM_RESET.

Diese geteilte Architektur — SPI fuer Schreibvorgaenge, GPIO-Parallelbus fuer Lesevorgaenge — entspricht den relativen Leistungsmerkmalen des SSD202: SPI ist getaktet und zuverlaessig fuer Mehrbyte-Schreibvorgaenge, waehrend der direkte GPIO-Registerzugriff die niedrigste moegliche Leselatenz zum Abtasten des Buszustands innerhalb eines Z80 T-State-Fensters bietet.

Der CPLD-Bitstrom wird mit Altera Quartus II 13.0.1 SP1 Web Edition erstellt, die als kostenloser Download von der Intel FPGA (ehemals Altera) Website verfuegbar ist. Die Web Edition unterstuetzt alle MAX7000AE-Bauelemente und ist fuer dieses Projekt ausreichend. Oeffnen des Projekts
Jede Host-Maschinen-Variante hat ihr eigenes Quartus-Projekt im entsprechenden Unterverzeichnis. Um beispielsweise die MZ-80A-Variante zu erstellen:

# In der Quartus II GUI oeffnen:
File -> Open Project -> CPLD/v1.0/MZ80A/build/tzpuFusionX_MZ80A.qpf

# Oder von der Kommandozeile mit der Quartus-Shell starten:
quartus_sh --flow compile tzpuFusionX_MZ80A

Das Projekt referenziert drei VHDL-Quelldateien (Pfade relativ zum Projektverzeichnis build/):

• ../tzpuFusionX_Toplevel.vhd — Top-Level-Entity-Instanziierung und E/A-Pin-Definitionen
• ../tzpuFusionX_pkg.vhd — Geteiltes Paket (Typen, Konstanten)
• ../tzpuFusionX.vhd — Haupt-RTL-Architektur (FSMs, SPI, Bus-Schnittstelle, Video-/Audiosteuerung)

Kompilierung
Waehlen Sie in der Quartus GUI Processing → Start Compilation (oder druecken Sie Strg+L). Das Tool fuehrt Analyse & Synthese, Fitter, Assembler und Timing-Analyse nacheinander aus. Ein erfolgreicher Build erzeugt:

build/output_files/tzpuFusionX_MZ80A.pof   # Programmer Object File (JTAG-Programmierung)
build/output_files/tzpuFusionX_MZ80A.fit.rpt  # Fitter-Bericht (Ressourcennutzung)
build/output_files/tzpuFusionX_MZ80A.sta.rpt  # Timing-Analyse-Bericht

Die .pof-Datei ist das Binaerimage, das zur Programmierung des physischen CPLD-Bauelements verwendet wird. Programmierung des CPLD
Die Programmierung erfolgt ueber JTAG mit einem Altera USB-Blaster oder kompatiblen JTAG-Adapter, der an den 10-Pin JTAG-Header auf der FusionX-Platine angeschlossen wird:

1. Verbinden Sie den USB-Blaster mit dem FusionX JTAG-Header und dem Host-PC.
2. Versorgen Sie die FusionX-Platine mit Strom (das CPLD muss waehrend der Programmierung mit Strom versorgt werden).
3. Oeffnen Sie in Quartus II Tools → Programmer.
4. Laden Sie die Kettenbeschreibungsdatei: build/output_files/tzpuFusionX_MZ80A.cdf.
5. Ueberpruefen Sie, ob der USB-Blaster in der Hardware-Liste erkannt wird, und klicken Sie dann auf Start.
6. Die Programmierung ist in wenigen Sekunden abgeschlossen; das CPLD wird unmittelbar nach Abschluss aktiv.

Das CPLD behaelt seine programmierte Logik unbegrenzt ohne Strom bei (MAX7000AE verwendet EEPROM-basierte Konfigurationszellen), sodass das Bauelement nur einmal pro Build oder bei Aktualisierung auf einen neuen Bitstrom programmiert werden muss.

Der FusionX-Softwarestack erstreckt sich vom Linux-Betriebssystem ueber dedizierte Kernelmodule bis hin zu User-Space-Dienstprogrammen. Der gesamte Software-Satz wird mit einer angepassten SigmaStar-Buildumgebung erstellt und auf den SPI NAND-Flash des SOM geladen. Beim Booten initialisiert U-boot das SOM und uebergibt an den Linux-Kernel, der das Buildroot-Rootdateisystem laedt. Das FusionX-Startskript konfiguriert dann das System und bringt den Z80-Emulator online. Die Softwarekomponenten sind:

• Linux OS
  — Kernel 4.9-rt (PREEMPT_RT) mit Buildroot-Rootdateisystem auf dem SigmaStar SSD202 Dual-Core Cortex-A7.
• z80drv.ko
  — Linux-Kernelmodul, das den Z80-CPU-Emulator und die Host-Hardware-Schnittstelle implementiert. Fuehrt die Z80-Emulationsschleife auf einem dedizierten CPU-Kern aus.
• ttymzdrv.ko
  — Linux TTY-Kernelmodul, das die Sharp MZ-Tastatur und das Display als Standard-Linux-Terminalgeraet (/dev/ttymz0) praesentiert.
• z80ctrl
  — User-Space-Befehlszeilendienstprogramm zur Steuerung des z80drv-Kernelmoduls: ROM-Images laden, virtuelle Hardware-Geraete hinzufuegen, Emulation starten/stoppen und emulierten Speicher untersuchen.
• k64fcpu
  — User-Space-Daemon, der eine virtuelle K64F-CPU emuliert. Wird im TZFS-Modus verwendet, um das ROM-Laden und die Interprozessor-Kommunikation mit dem Z80-Emulator zu verwalten.
• sharpbiter
  — Sharp MZ Arbiter-Daemon, der den Zugriff auf die gemeinsam genutzten Sharp MZ-Hardwareressourcen zwischen dem Z80-Emulator und dem Linux-TTY-Treiber koordiniert.

Der Start wird von start_FusionX.sh gehandhabt, das ttymzdrv.ko laedt, eine Getty-Anmeldesitzung auf /dev/ttymz0 startet, alle Linux-Prozesse und IRQs an CPU0 bindet, z80drv.ko auf die isolierte CPU1 laedt und dann die k64fcpu- und sharpbiter-Daemons startet. Zwei vorgefertigte Startmodi werden bereitgestellt:

• RFS-Modus
  (startZ80_RFS.sh) — laedt das ROM Filing System Virtual Hardware Device und startet den MZ-80A-Emulator mit 40- oder 80-Spalten-ROM-Images.
• TZFS-Modus
  (startZ80_TZFS.sh) — laedt das tranZPUter SW Virtual Hardware Device und startet den k64fcpu K64F-Daemon, der das Laden von Monitor- und TZFS-ROM-Images verwaltet.

Die FusionX-Softwarearchitektur ist geschichtet, wobei jede Schicht eine bestimmte Verantwortung traegt. Aus der Perspektive der Host-Maschine ist der Ablauf voellig transparent — der Z80-Sockel verhaelt sich wie eine normale Z80-CPU, waehrend das SOM stillschweigend jeden Buszyklus abfaengt und emuliert.

 Sharp MZ Host
 +------------------------------------------+
 |  Z80 DIP-40 Socket                       |
 +--------------+---------------------------+
                |  Z80 bus (address, data, control)
 +--------------v---------------------------+
 |  CPLD (Altera MAX 7000A)                 |
 |  . 5V <-> 3.3V level translation        |
 |  . Cycle-accurate Z80 bus timing         |
 |  . 50 MHz internal clock                 |
 +--------------+---------------------------+
                |  SPI (50 MHz) + 8-bit GPIO bus
 +--------------v---------------------------+
 |  SSD202 SOM -- CPU1 (dedicated)          |
 |  +--------------------------------------+|
 |  |  z80drv.ko kernel module             ||
 |  |  +----------------------------------+||
 |  |  |  z80io.c  (GPIO/SPI HAL)         |||
 |  |  +----------------------------------+||
 |  |  |  Zeta Z80 CPU emulator core      |||
 |  |  +----------------------------------+||
 |  |  |  Virtual hardware modules        |||
 |  |  |  (z80vhw_*.c, inline)            |||
 |  |  +----------------------------------+||
 |  +--------------------------------------+|
 |                                          |
 |  SSD202 SOM -- CPU0 (Linux)              |
 |  +--------------------------------------+|
 |  |  Linux 4.9-rt  /  Buildroot rootfs  ||
 |  |  ttymzdrv.ko  -->  /dev/ttymz0      ||
 |  |  z80ctrl  (control utility)          ||
 |  |  k64fcpu  (K64F daemon)              ||
 |  |  sharpbiter  (MZ arbiter)            ||
 |  +--------------------------------------+|
 +------------------------------------------+

Die beiden Cortex-A7-Kerne des SSD202 arbeiten unter einer strikten Aufgabentrennung. Beim Start werden alle Linux-Prozesse und alle Hardware-IRQ-Affinitaeten auf CPU0 migriert, sodass CPU1 ausschliesslich fuer den Z80-Emulations-Kernel-Thread zur Verfuegung steht. Der CPU-Frequenzregler wird nach dem Start des Emulators auf Leistungsmodus (1,2 GHz fest) eingestellt, um zu verhindern, dass Frequenzskalierungsuebergaenge Timing-Variationen in der Emulationsschleife einfuehren. CPU0 — Linux und User-Space-Dienste
Fuehrt das vollstaendige Linux 4.9-rt Betriebssystem, alle User-Space-Daemons aus und verarbeitet alle Hardware-Interrupts. Hauptverantwortlichkeiten auf CPU0 sind:

• ttymzdrv.ko
  — Linux TTY-Kernelmodul, das die Sharp MZ-Tastatur und das Display auf /dev/ttymz0 abbildet. Unterstuetzt Anhalten und Fortsetzen, sodass der Benutzer nahtlos zwischen einer Z80-Sitzung und einer Linux-Konsole am Host-Rechner wechseln kann, ohne den Zustand in einer der beiden zu verlieren.
• z80ctrl-Dienstprogramm
  — Befehlszeilentool fuer die Laufzeitsteuerung des Z80-Emulators: Laden von ROM-Images, Registrieren virtueller Hardware-Geraete, Starten und Stoppen der Emulationsschleife und Untersuchen des emulierten Speichers. Kommuniziert mit z80drv.ko ueber ein Kernel-Zeichengeraet.
• k64fcpu-Daemon
  — User-Space-Daemon, der eine virtuelle K64F-CPU emuliert. Aktiv im TZFS-Modus; er verwaltet das Laden von Monitor- und TZFS-ROM-Images in den Speicherbereich des Emulators und leitet Interprozessor-Befehle an z80drv.ko weiter.
• sharpbiter-Daemon
  — Sharp MZ Arbiter; koordiniert den Zugriff auf die gemeinsam genutzte Sharp MZ-Tastatur- und Display-Hardware zwischen dem TTY-Treiber und dem Z80-Emulator, damit beide ohne Konflikte an den zugrunde liegenden E/A-Registern arbeiten koennen.
• WLAN und Webserver
  — Der im SOM integrierte 802.11 b/g/n-Transceiver (SSW101B) bietet Netzwerkkonnektivitaet. Ein leichtgewichtiger Webserver auf CPU0 kann Konfigurations- und Statusseiten bereitstellen, und der WLAN-Stack ermoeglicht OTA-Firmware-Lieferung ueber die SD-Karten-Auto-Upgrade-Funktion beim Booten.

CPU1 — Z80-Emulator (dediziert)
Fuehrt ausschliesslich den kthread_z80 Kernel-Thread aus, der von z80drv.ko erzeugt wird. Kein anderer Prozess oder Interrupt wird nach der Initialisierung jemals auf CPU1 geplant. Die Emulationsschleife auf CPU1:

• Ruft den Zeta Z80-CPU-Kern fuer jeden Befehlsausfuehrungsschritt auf
• Leitet jeden resultierenden Speicher- oder E/A-Zugriff an den richtigen Handler weiter — physische Host-Hardware, kernelresidentes RAM-Image oder eine Funktion eines virtuellen Hardware-Moduls
• Steuert die GPIO- und SPI-Hardware ueber z80io.c, um Z80-Bussignale ueber das CPLD zu aktivieren oder abzutasten
• Laeuft mit 1,2 GHz, wobei der PREEMPT_RT-Kernel minimales Interrupt-Jitter auch bei CPU0-Aktivitaet gewaehrleistet

Der Hardwarepfad vom SOM zum Z80-Host-Sockel fuehrt durch ein Altera MAX 7000A CPLD. Dieses Bauelement dient zwei wesentlichen Rollen:

• Spannungspegelumsetzung
  — Das CPLD ist 5V-tolerant an seinen Eingaengen und treibt Ausgaenge mit 3,3V Low Voltage TTL-Pegeln. Da die 5V TTL-Schaltschwelle bei etwa 2,4V liegt, kann das CPLD die 5V-Hostlogik direkt mit bis zu 25 mA pro Pin ansteuern, was die Platine mit unmodifizierter historischer Z80-Hardware kompatibel macht.
• Zyklusgenaues Z80-Bustiming
  — Das CPLD bettet Zustandsmaschinen ein, die von einem externen 50 MHz-Oszillator getaktet werden. Diese Zustandsmaschinen tasten den Z80-Host-Takt ab und reproduzieren die praezise T-State-Sequenz fuer jeden Buszyklus (Fetch, Memory Read/Write, I/O Read/Write) gemaess den Z80-Zustandsdiagrammen. Das bedeutet, dass das SOM-Kernelmodul kein sub-Mikrosekunden-Z80-Timing in Software replizieren muss — das CPLD handhabt es in Hardware.

Das SOM kommuniziert mit dem CPLD ueber zwei parallele Kanaele:

• SPI-Kanal (50 MHz)
  — wird zum Schreiben von Daten und Befehlen an das CPLD verwendet. SPI-Schreiben wird gegenueber GPIO fuer Hostbus-Schreibvorgaenge bevorzugt, da es getaktet und daher fuer Mehrbyte-Transfers bei hoher Geschwindigkeit zuverlaessiger ist.
• 8-Bit GPIO-Bus
  — wird von z80io.c zum Lesen von Busstatus und Adress-/Datenwerten vom CPLD verwendet. Der direkte Registerzugriff wird verwendet (unter Umgehung der SigmaStar HAL API nach der Initialisierung), um die Leselatenz zu minimieren. Der maximal erreichbare Lesedurchsatz ueber die SSD202 GPIO-Struktur betraegt etwa 2 MB/s fuer ein 8-Bit-Byte — schnell genug, um Z80-Buszyklen bei typischen Host-Taktraten (1 MHz-6 MHz) zu bedienen, wenn mit der CPLD-Pufferung kombiniert.

Da der GPIO-Lesedurchsatz eine Obergrenze fuer die Bustransaktionsrate setzt, werden Z80-Programme aus kernelresidenten Speicher-Images ausgefuehrt, anstatt bei jedem Zugriff aus dem physischen Host-Speicherbus gelesen zu werden. ROM-Images werden beim Start in den Kernelspeicher geladen, und alle Speicherzugriffe des emulierten Z80 werden von dort bedient — der physische Hostbus wird nur dann aktiviert, wenn ein PHYSICAL-Typ-Block angetroffen wird (z.B. fuer Host-Video-RAM oder Hardware-Register, die auf der realen Hardware zugegriffen werden muessen).

Die 128 MB DRAM auf dem SSD202 SOM werden zwischen dem Linux-Betriebssystem und dem Z80-Kernelmodul geteilt. Das Kernelmodul reserviert einen zusammenhaengenden Bereich physisch adressierten Kernelspeichers, um ROM- und RAM-Images fuer den emulierten Z80 aufzunehmen. Dieser Bereich wird direkt vom kthread_z80 auf CPU1 zugegriffen, ohne Overhead durch virtuelle Speicheruebersetzung in der inneren Emulationsschleife. Der emulierte Z80 sieht eine konfigurierbare Speicherabbildung ueber den Standard 64 KB (0x0000-0xFFFF) Adressraum. Jedem Bereich wird einer der folgenden Zugriffstypen zugewiesen:

ROM-Images werden beim Start durch z80ctrl --loadrom in den Kernelspeicher geladen (oder automatisch durch das aktive Virtual Hardware Module oder den k64fcpu-Daemon im TZFS-Modus). Mehrere ROM-Seitensaetze koennen gleichzeitig resident sein — das RFS Virtual Hardware Module verwaltet beispielsweise bis zu vier umschaltbare ROM-Seiten (MROM, User ROM I/II/III) fuer 40-Spalten- und 80-Spalten-Konfigurationen. Maschinen-Timing-Konstanten fuer jeden unterstuetzten Host (MZ-80A, MZ-700, MZ-2000, PCW-8256) sind in z80driver.h definiert und werden von der Emulationsschleife verwendet, um Buszyklen mit der korrekten Rate relativ zum Host-Takt zu takten, um sicherzustellen, dass zeitkritische Software (Bandmotorsteuerung, serielle E/A, Verzoegerungsschleifen) sich so verhaelt, wie auf der Originalhardware.

Virtuelle Hardware-Module sind C-Quelldateien (z80vhw_*.c), die das Verhalten einer bestimmten Host-Maschine oder eines Peripherie-Satzes definieren. Statt als separat gelinkte Objekte kompiliert zu werden, werden sie direkt in z80driver.c per #include eingebunden, sodass ihre Handler-Funktionen ohne Funktionsaufruf-Overhead in den Emulations-Dispatch-Pfad eingebettet werden. Bis zu fuenf virtuelle Hardware-Geraete koennen gleichzeitig aktiv sein (MAX_VIRTUAL_DEVICES 5). Geraete werden zur Laufzeit vor dem Start des Emulators mit z80ctrl --adddev --device <name> registriert. Jedes registrierte Geraet erhaelt Callbacks fuer Memory Read, Memory Write, I/O Read und I/O Write fuer die Adressbereiche, die es beansprucht, und kann optional seine eigenen ROM-Images installieren und die Speicherabbildung waehrend der Initialisierung konfigurieren. Die verfuegbaren Module und die von ihnen unterstuetzten Host-Maschinen sind:

Das TZPU-Modul (z80vhw_tzpu.c) unterscheidet sich architektonisch von den anderen. Da das K64F-Coprozessor-Verhalten komplex und zustandsbehaftet ist, ist es auf zwei Komponenten aufgeteilt: der z80vhw_tzpu.c Kernel-seitige Stub behandelt den schnellen Buszyklus-Dispatch, waehrend der k64fcpu User-Space-Daemon auf CPU0 das ROM-Laden, die Speicherbank-Auswahl und die hoehere K64F-Befehlsverarbeitung verwaltet. Die beiden Haelften kommunizieren ueber einen gemeinsamen Speicherbereich im Kernelmodul.

Der schnellste Weg, jede FusionX-Komponente zu bauen — die Z80-Assembler-ROMs, TZFS und CP/M, die Linux-Kernelmodule und SPI-Tools, die CPLD-Bitstreams und das vollstaendige SigmaStar SSD202 Linux-SD-Image — ist das mitgelieferte Setup-Skript fuer Ihre Plattform. Jedes Skript ist eigenstaendig: kopieren Sie nur die eine Datei und fuehren Sie sie aus. Es installiert die benoetigten Werkzeuge, klont das Repository mit seinen Submodulen (standardmaessig nach ~/FusionX), laedt das SharpSoft-Content-Bundle herunter (TZFS_Files.zip, ~110 MB), bereitet die Werkzeugkette vor und bietet an, den ersten Build auszufuehren. Die manuellen Schritte pro Komponente weiter unten bleiben fuer fortgeschrittene Benutzer und Teil-Rebuilds verfuegbar.

chmod +x setup_FusionX.sh
./setup_FusionX.sh

Windows 10/11 — doppelklicken Sie setup_FusionX_windows.cmd, oder aus einer PowerShell-Eingabeaufforderung:

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

Der Build selbst 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). Bauen Sie alles, oder uebergeben Sie ein oder mehrere Flags fuer eine einzelne Komponente:

./build.sh                 # all components
./build.sh --cpld          # just the CPLD bit streams
./build.sh --help          # list all options

Praktische Umgebungsvariablen-Ueberschreibungen (alle optional):

Fuer die manuellen Build-Details pro Komponente — einschliesslich des systemnahen Build_FusionX.sh Image-Builds — siehe Build weiter unten.

Das vollstaendige FusionX-Betriebssystem und der Anwendungssatz wird mit dem Build_FusionX.sh-Skript erstellt, das das SigmaStar SDK-Build-System umschliesst und ein flashfertiges NAND-Image erzeugt. Zum Erstellen wird ein Linux-Host mit installierter ARM-Cross-Compiler-Toolchain benoetigt. Voraussetzungen

• ARM-Cross-Compiler: arm-linux-gnueabihf-gcc (z.B. aus dem Paket gcc-arm-linux-gnueabihf)
• SigmaStar SDK-Quellbaum (Kernel, U-boot, Buildroot) in der von Build_FusionX.sh erwarteten uebergeordneten Verzeichnisstruktur
• FusionX-Anwendungsquelle im Verzeichnis ../FusionX relativ zum Linux-Build-Verzeichnis
• Standard-Build-Tools: make, cmake, bc, libssl-dev

Erstellen des vollstaendigen Betriebssystem-Images Der Build wird aus dem Verzeichnis software/linux/ gestartet:

# Vollstaendiges Image fuer FusionX erstellen (Projekt 2D06, SPI NAND, SSD202, 256MB Flash)
./Build_FusionX.sh -f nand -p ssd202 -o 2D06 -m 256

Dies erstellt der Reihe nach: U-boot-Bootloader, Linux-Kernel (unter Verwendung der benutzerdefinierten FusionX-Defconfig infinity2m_spinand_fusionx_defconfig), Buildroot-Rootdateisystem und den FusionX-Anwendungssatz. Ausgabe-Images werden in project/image/output/images/ geschrieben. Fuer die Standard-SigmaStar-Referenzkonfiguration verwenden Sie stattdessen Projekt 2D07. Nur Kernelmodule erstellen Die Kernelmodule koennen unabhaengig gegen einen bereits erstellten Kernel-Baum neu erstellt werden, was waehrend der Entwicklung nuetzlich ist:

# z80drv-Kernelmodul erstellen
cd software/FusionX/src/z80drv/src.mz80a
make

# ttymzdrv-Kernelmodul erstellen
cd software/FusionX/src/ttymz
make

Die resultierenden z80drv.ko- und ttymzdrv.ko-Dateien koennen direkt in das Verzeichnis /apps/FusionX/modules/ auf dem laufenden SOM kopiert (ueber SSH oder SD-Karte) und mit insmod geladen werden. Flashen und Updates Das vom Build-Skript erzeugte Flash-Image wird ueber das SigmaStar ISP-Tool per USB auf den SOM SPI NAND programmiert. Nach der Erstinstallation koennen nachfolgende Updates ueber die SD-Karte bereitgestellt werden — wenn das SOM mit einer entsprechend vorbereiteten SD-Karte beim Booten startet, aktualisiert es automatisch das NAND-Image, ohne dass eine USB-Verbindung erforderlich ist.

Die Linux-Plattform laeuft auf dem SigmaStar SSD202 (Infinity2M) SOM — einem 29mm x 29mm Stamp-Modul, das eine Dual-Core ARM Cortex-A7 bei 1,2 GHz, 128 MB DRAM, 256 MB SPI NAND Flash und einen integrierten 802.11 b/g/n WLAN-Transceiver enthaelt. Der Kernel ist Linux 4.9 mit dem PREEMPT_RT-Echtzeitpatch, der die Scheduling-Latenz minimiert, was fuer eine reaktionsschnelle Z80-Emulation unerlaeasslich ist. Das vollstaendige Betriebssystem-Image — U-boot-Bootloader, Linux-Kernel, Buildroot-Rootdateisystem und FusionX-Anwendungssatz — wird mit dem Skript Build_FusionX.sh zusammengestellt, einer angepassten Version des SigmaStar SDK-Build-Systems. Zwei Projektziele sind definiert:

• 2D06
  — Benutzerdefinierte FusionX-Konfiguration unter Verwendung der Kernel-Defconfig infinity2m_spinand_fusionx_defconfig.
• 2D07
  — Standard-SigmaStar-Referenzkonfiguration unter Verwendung von infinity2m_spinand_ssc011a_s01a_minigui_defconfig.

Das Build-Skript wird aufgerufen als: Build_FusionX.sh -f nand -p ssd202 -o 2D06 -m 256 und erzeugt ein vollstaendiges Flash-Image, bereit zur Programmierung auf den SOM NAND. Ein wesentlicher Aspekt der Linux-Konfiguration ist die CPU-Isolation. Beim Start werden alle Linux-Prozesse und Hardware-IRQs auf CPU0 migriert. CPU1 wird dann ausschliesslich dem kthread_z80-Kernel-Thread gewidmet, der die Z80-Emulationsschleife ausfuehrt. Diese CPU-Affinitaetstrennung, kombiniert mit dem PREEMPT_RT-Kernel, gibt dem Z80-Emulator den konsistentesten und latenzaermsten Zugang zur Host-Hardware-Schnittstelle. Der CPU-Leistungsregler wird ebenfalls auf maximale Frequenz (1,2 GHz) eingestellt, nachdem der Z80-Emulator laeuft, um zu vermeiden, dass Frequenzskalierung Timing-Variationen in der Emulationsschleife verursacht. Das Rootdateisystem ist eine Buildroot-basierte minimale Linux-Umgebung, die im SOM NAND Flash gespeichert ist. Eine optionale SD-Karte kann den Speicher fuer Sharp MZ-Anwendungssoftware, ROM-Images und zusaetzliche Linux-Dienstprogramme erweitern. Wenn eine entsprechend vorbereitete SD-Karte beim Booten vorhanden ist, aktualisiert das SOM automatisch, was Firmware-Updates vereinfacht.

Der Z80-Emulator ist als Linux-Kernelmodul implementiert, z80drv.ko (v1.4, April 2023). Er verwendet die Zeta Z80 CPU-Emulator-Bibliothek von Manuel Sainz de Baranda y Goni als seinen Z80-Befehlssatzkern, eingebettet in einen Kernel-Space-Treiber, der mit der SSD202 GPIO-Hardware und der CPLD Z80-Host-Schnittstelle zusammenarbeitet. Der Hardwarepfad vom SOM zum Z80-Host-Sockel verlaeuft: SSD202 GPIO / SPI → CPLD → Z80 DIP-40-Sockel. Das CPLD handhabt genaues Z80-Bustiming mit einem 50 MHz-Takt, sodass das Kernelmodul kein praezises T-State-Timing selbst reproduzieren muss. Die GPIO-Schnittstelle wird von z80io.c verwaltet, das die SigmaStar HAL fuer die Initialisierung aufruft, aber fuer Bit-Level-Lese-/Schreiboperationen direkt auf Register zugreift, um die Latenz zu minimieren. Der praktische Lesedurchsatz der SSD202 GPIO-Struktur betraegt etwa 2 MB/s fuer ein 8-Bit-Byte, was bedeutet, dass Programme aus dem emulierten (Kernel-)Speicher ausgefuehrt werden und nicht aus dem physischen Host-Speicher ueber den Bus. Der Emulator unterstuetzt die folgenden Host-Maschinen, jede mit ihrem eigenen Virtual Hardware Module:

Virtual Hardware Module	Host-Maschine	Beschreibung
z80vhw_mz80a.c	Sharp MZ-80A	Original MZ-80A behaviour, no additions
z80vhw_mz700.c	Sharp MZ-700	Original MZ-700 behaviour, no additions
z80vhw_mz2000.c	Sharp MZ-2000	MZ-2000 emulation
z80vhw_pcw.c	Amstrad PCW-8256	PCW-8256 emulation
z80vhw_rfs.c	MZ-80A + RFS	ROM Filing System virtual hardware for MZ-80A
z80vhw_tzpu.c	MZ-80A + tranZPUter SW	tranZPUter SW virtual hardware; combines kernel driver with userspace k64fcpu daemon

Die Virtual Hardware Module werden inline in z80drv.ko kompiliert, anstatt als separate Objekte gelinkt zu werden, was den Funktionsaufruf-Overhead im Emulations-Hotpath eliminiert. Bis zu fuenf virtuelle Hardware-Geraete koennen gleichzeitig aktiv sein (MAX_VIRTUAL_DEVICES 5). Geraete werden zur Laufzeit mit z80ctrl --adddev --device <name> hinzugefuegt, bevor der Emulator gestartet wird. Das z80ctrl-Dienstprogramm bietet vollstaendige Laufzeitsteuerung des Emulators von der Linux-Befehlszeile:

• --adddev --device <name> — ein virtuelles Hardware-Geraet hinzufuegen (rfs, tzpu, mz700, mz80a, mz2000, pcw)
• --start / --stop — die Z80-Emulationsschleife starten oder stoppen
• --loadrom --file <path> --addr <hex> --type <n> — ein ROM-Binary in den emulierten Speicher laden
• --mem --addr <hex> --len <n> — den emulierten Speicherinhalt untersuchen
• --cmd <hex> — ein Befehlsbyte direkt an das CPLD/Z80-Gateway senden

Das ttymzdrv.ko-Modul (ttymz.c, v1.2, Juli 2023) bietet eine Standard-Linux-TTY-Schnittstelle auf /dev/ttymz0, gestuetzt durch die Sharp MZ-Tastatur- und Display-Hardware. Dies ermoeglicht die Verwendung der Konsole der Host-Maschine als Linux-Terminal — mit einer Getty-Anmeldesitzung — waehrend gleichzeitig Anhalten und Fortsetzen unterstuetzt wird, um das Display zwischen Linux und der Z80-Emulationssitzung umzuschalten, ohne den Zustand zu verlieren. Unterstuetzte Hosts sind MZ-80A, MZ-700 und MZ-2000.

Die tranZPUter-Serie wurde urspruenglich im Sharp MZ-80A entwickelt und war primaer ein Z80-Ersatz. Als das Konzept sich weiterentwickelte und der tranZPUter SW-700 fuer den MZ-700 entwickelt wurde, wurde er mehr zu einer integralen Komponente der Maschine und bot originale und erweiterte Video- und Audio-Faehigkeiten durch Abfangen und Weiterleiten vorhandener Signale. Nach bedeutenden Entwicklungen am tranZPUter SW-700 wurde es wuenschenswert, ihn zurueck auf den MZ-80A und MZ-2000 zu portieren, aber diese Maschinen hatten eine andere CPU-Ausrichtung und Signalanforderungen, z.B. das Ansteuern eines internen und externen Monitors. Diese Anforderung fuehrte zum Konzept der Tochterplatinen, wobei eine spezifische Platine fuer den Zielhost entworfen und entwickelt werden wuerde und in die tranZPUter SW-700-Karte gesteckt werden konnte. Idealerweise wollte ich den SW-700 auf einen MZ-800/MZ-1500 und X1 portieren, aber die Groesse der Karte und die Ausrichtung des Z80 war eine Einschraenkung. Waehrend des Designs des tranZPUter^FusionX war eine der Hauptanforderungen, die Platine klein zu machen, die Z80-Ausrichtung aenderbar und auch kompatibel mit dem tranZPUter^Fusion, damit sie in viele Maschinen passt und austauschbar ist. Da der SW-700 auch mit dem Video und Audio der Maschinen verbunden war und jedes recht unterschiedlich war, wurde offensichtlich, dass der tranZPUter^FusionX ein Konzept enthalten musste, um verschiedene Video-/Audio-Schnittstellen je nach Zielhost zu ermoeglichen. Dieses Konzept wurde ueber Tochterplatinen realisiert. Zwei Anschluesse wuerden den tranZPUter^FusionX mit einer Tochterplatine verbinden, die speziell fuer den beabsichtigten Host entworfen wurde. Die Tochterplatinen waeren verantwortlich fuer das Umschalten und Mischen von Video-/Audiosignalen und das Ansteuern interner Monitore sowie die Bereitstellung der korrekten Eingangs- und Ausgangsanschluesse fuer eine einfache Installation. Derzeit wurden drei Tochterplatinen entwickelt, fuer den MZ-700, MZ-80A und MZ-2000, und weitere werden folgen, wenn das Design voranschreitet.

Der Zweck der MZ-700 Tochterplatine ist die Anbindung der Video-/Audioschaltkreise der FusionX-Platine an die des MZ-700. Sie ist dafuer konzipiert, in den Mainboard-Modulatorausgang eingesetzt zu werden, wobei der Modulatoranschluss wiederum mit der Tochterplatine verbunden wird. Dies ermoeglicht die Verwendung des MZ-700 mit einem Standardmonitor, wobei der Videoausgang unter Kontrolle des FusionX zwischen MZ-700 und FusionX umgeschaltet wird. Die Original-Tonsschaltung des MZ-700 steuert einen Lautsprecher direkt an, und um FusionX-Audio in den MZ-700-Lautsprecher einzuspeisen, wird der Mainboard-Lautsprecherausgang zur Tochterplatine geleitet, pegelgewandelt und unter Kontrolle des FusionX umgeschaltet. Der FusionX bietet Stereosound, der selektiv mit dem Original-MZ-700-Sound umgeschaltet/gemischt und einem Class-D-Verstaerker zugefuehrt wird, der dann den internen Lautsprecher ansteuert. Line-Level-Stereoausgang wird ueber einen zusaetzlichen 4-Pin-Anschluss erreicht und nach Bedarf verwendet. Diese Konfiguration ermoeglicht es Linux oder emulierten Maschinen, waehrend sie als Anwendung auf dem FusionX laufen, ihren Sound ueber den internen Lautsprecher auszugeben.

Die MZ-700 Tochterplatine besteht aus drei 4-Wege SPDT-Analogschaltern zum Routing von Video- und Audiosignalen unter FusionX-Steuerung und einem Class-D-Leistungsverstaerker.

Die MZ-700 Tochterplatine PCB ist aufgrund der Platzbeschraenkungen klein und kompakt. Sie muss auf den vorhandenen Modulatoranschluss passen und in den verfuegbaren Freiraum.

Der Zweck der MZ-2000 Tochterplatine ist die Anbindung der Video-/Audio-/Reset-Schaltkreise der FusionX-Platine an die des MZ-2000. Der MZ-2000 hat eine interne monochrome Kathodenstrahlroehre, externen RGB-Videoausgang und internes Audio mit einem Verstaerker auf der Monochrom-CRT-Steuerplatine. Die Tochterplatine ist dafuer konzipiert, gleichzeitig in die Mainboard-Monitor- und IPL-Anschluesse eingesetzt zu werden. Sie praesentiert alle erforderlichen Anschluesse fuer IPL/RESET-Schalter, internen Monitor und externen Monitor auf der gleichen Platine. Die IPL- und RESET-Eingaenge werden auf der Tochterplatine abgefangen und an den FusionX gesendet, da der MZ-2000 in verschiedenen Modi arbeitet, abhaengig davon, welche RESET-Taste waehrend eines Z80-Resets gedrueckt wird. Die Videosignale vom Mainboard werden mit den monochromen FusionX-Videosignalen umgeschaltet und an den internen CRT-Monitor gesendet. Dies ermoeglicht originale Videoausgabe auf dem CRT-Monitor oder erweiterte FusionX-Text- und Grafikdarstellung, Aufloesung abhaengig von den Timing-Einschraenkungen des Monitors. Der FusionX RGB-Ausgang wird zur externen RGB-Videobuchse des MZ-2000 geleitet und ermoeglicht bis zu Full-HD externen Farbvideoausgang. Die Tonsschaltung des MZ-2000 wird an einen Audioverstaerker auf dem CRT-Monitor gesendet. Dieses Signal wird abgefangen und mit dem FusionX-Audio umgeschaltet, das dann den CRT-Monitor-Verstaerker ansteuert. Line-Level-Stereoausgang wird ueber einen zusaetzlichen 4-Pin-Anschluss erreicht und nach Bedarf verwendet.

Die MZ-2000 Tochterplatine besteht aus zwei 4-Wege SPDT-Analogschaltern zum Routing von Video- und Audiosignalen unter FusionX-Steuerung. Ein SPDT-Schalter wird verwendet, um reines Schwarz im modifizierten Videosignal zu erzeugen, das auf der FusionX-Platine generiert wird.

Die MZ-2000 Tochterplatine PCB ist aufgrund der Platzbeschraenkungen und der Anzahl der Anschluesse, die sie tragen muss, klein und kompakt. Sie wird in die Mainboard-Monitor/IPL-Steckerleisten gesteckt und praesentiert dann neue CRT-Monitor-, externe Video- und IPL/RESET-Schalteranschluesse fuer die gesamte vorhandene interne Verkabelung.

Der Zweck der MZ-80A Tochterplatine ist die Anbindung der Video-/Audio-/Reset-Schaltkreise der FusionX-Platine an die des MZ-80A. Der MZ-80A hat eine interne monochrome Kathodenstrahlroehre, Aussparungen fuer eine externe RGB-Videobuchse und internes Audio mit einem Verstaerker auf der Monochrom-CRT-Steuerplatine. Die Tochterplatine ist dafuer konzipiert, in den vertikalen Mainboard-CRT-Videoanschluss mit einem Spalt eingesetzt zu werden, damit der Datenkassettenanschluss gleichzeitig angeschlossen werden kann. Der Spalt ist notwendig, da der CRT-Videoanschluss nahe an der hinteren Seitenwand sitzt, sodass die Tochterplatine sich nach vorne zur Tastatur erstrecken muss. Sie praesentiert alle erforderlichen Anschluesse fuer den RESET-Schalter (Ein- und Ausgang), internen Monitor und externen Monitor auf der gleichen Platine. Der RESET-Eingang wird auf der Tochterplatine abgefangen und an den FusionX gesendet. Technisch ist es nicht notwendig, da der FusionX den Z80-Reset abtastet, der auf diesem Eingang basiert, aber es kann nuetzlich sein, z.B. zur Erkennung von Anforderungen zum Neustart des SOM (Doppeldruck) statt der MZ-80A-Schaltung. Die Videosignale vom Mainboard werden mit den monochromen FusionX-Videosignalen umgeschaltet und an den internen CRT-Monitor gesendet. Dies ermoeglicht originale Videoausgabe auf dem CRT-Monitor oder erweiterte FusionX-Text- und Grafikdarstellung, Aufloesung abhaengig von den Timing-Einschraenkungen des Monitors. Der FusionX RGB-Ausgang wird zur externen RGB-Videobuchse des MZ-80A (falls installiert) geleitet und ermoeglicht bis zu Full-HD externen Farbvideoausgang. Die Tonsschaltung des MZ-80A wird an einen Audioverstaerker auf dem CRT-Monitor gesendet. Dieses Signal wird abgefangen und mit dem FusionX-Audio umgeschaltet, das dann den CRT-Monitor-Verstaerker ansteuert. Line-Level-Stereoausgang wird ueber einen zusaetzlichen 4-Pin-Anschluss erreicht und nach Bedarf verwendet.

Die MZ-80A Tochterplatine besteht aus zwei 4-Wege SPDT-Analogschaltern zum Routing von Video- und Audiosignalen unter FusionX-Steuerung. Ein SPDT-Schalter wird verwendet, um reines Schwarz im modifizierten Videosignal zu erzeugen, das auf der FusionX-Platine generiert wird.

Die MZ-80A Tochterplatine PCB ist klein und kompakt mit einer grossen Ausstanzung, um die Verbindung mit dem Mainboard-CRT-Anschluss und den Durchgang des Datenkassetten-Signalanschlusses zu ermoeglichen. Sie wird in den Mainboard-CRT-Monitoranschluss gesteckt und praesentiert dann neue CRT-Monitor-, externe Video- und RESET Ein-/Ausgangs-Schalteranschluesse fuer die gesamte vorhandene interne Verkabelung.

Die folgende Tabelle enthaelt alle Websites, die im Design und in der Programmierung des tranZPUter^FusionX referenziert werden

Website	Sprache	Beschreibung
Z80 Emulation	English	A highly accurate Z80 Emulation written in C, the heart of the FusionX.
WhyCan Forum	Chinese	Invaluable Forum with threads on SigmaStar products.
SSD20X System Development Manual	Chinese	System development manual for the SSD20X CPU.
SigmaStarDocs	Chinese	SDK and API development manual.
SOM2D0X Beginners Guide	Chinese	Beginners Guide to the SOM2D0X.
CivetWeb Users Manual	English	User Manual for the CivetWeb Embedded Web Server.

Die folgende Tabelle enthaelt alle Datenblaetter und Handbuecher, die im Design und in der Programmierung des tranZPUter^FusionX referenziert werden

Datenblatt	Sprache	Beschreibung
ADV7123	English	Original 5V 30bit VideoDAC (discontinued)
GM7123	Chinese	Chinese 3.3V version of the ADV7123 30bit VideoDAC converter.
CH340E	Chinese	USB to Serial UART converter.
EPM7512AEQFP144	English	Altera 512 MacroCell 5V tolerant CPLD.
HXJ8002	English	Class D power amplifier.
SOM2D01	English	SigmaStar SOM Datasheet (original model).
REF3040	English	Precise 4V reference voltage generator.
SY6280	English	Power distribution switch, used for enabling and supplying USB Bus power.
TLC5602C	English	8bit VideoDAC converter.
TLV62569	English	High efficiency Buck Converter.
TMUX1134	English	Precision SPDT Analogue switch (Mux).
VCUT0714BHD1	English	ESD Protection Diode.
USB Programmer	English	SigmaStar USB Programmer for SSD202 Processor.
SSD201 HW Checklist v10	English	SigmaStar SSD201 Hardware Checklist.
SSD202D Reference v04	English	SigmaStar SSD202 CPU Reference Manual.
SOM2D02_Pinout	English	SigmaStar SOM2D02 Pinout.
Z80 UserManual	English	Z80 User Manual.
SSD202D Product Brief	English	SigmaStar SSD202 CPU Product Brief.
SOM2D01 Datasheet	English	SigmaStar SOM2D01 Datasheet.

Der Entwicklungsfortschritt des tranZPUter^FusionX wurde auf X (ehemals Twitter) geteilt, als jeder Meilenstein erreicht wurde. Die folgenden Beitraege dokumentieren wichtige Phasen von der ersten Hardware-Inbetriebnahme bis hin zum Betrieb von RFS-, MZ-700- und MZ-2000-Emulation: https://x.com/engineerswork1/status/1579209688495054849
https://x.com/engineerswork1/status/1583918702415577089
https://x.com/engineerswork1/status/1596925535787286528
https://x.com/engineerswork1/status/1616571495957909510
https://x.com/engineerswork1/status/1630985022604804109

Die im FusionX verwendete Z80-Emulation ist (c) 1999-2022 Manuel Sainz de Baranda y Goni, lizenziert unter der LGPL v3, Quellcode verfuegbar auf Gitea. Das SSD202/SOM2D0X Build-System basiert auf Linux mit Erweiterungen von SigmaStar und Industio, Lizenzierung kann in deren aktualisierten Quelldateien gefunden werden.

Dieses Design, Hardware und Software (zurechenbare Komponenten unter Ausschluss separat lizenzierter Software) ist unter der GNU Public Licence v3 lizenziert und frei zu verwenden, anzupassen und zu modifizieren durch Einzelpersonen, Gruppen und Bildungseinrichtungen. Keine kommerzielle Nutzung dieses Designs oder einer Hardware-/Firmware-Komponente ohne ausdrueckliche Genehmigung des Autors.

Die in diesem Projekt als GPL v3 gekennzeichneten Quell- und Binaerdateien sind freie Software: Sie koennen sie unter den Bedingungen der GNU General Public License, wie von der Free Software Foundation veroeffentlicht, weiterverbreiten und/oder modifizieren, entweder unter Version 3 der Lizenz oder (nach Ihrer Wahl) einer spaeteren Version.

Die Quelldateien werden in der Hoffnung verteilt, dass sie nuetzlich sind, aber OHNE JEDE GEWAEHRLEISTUNG; auch ohne die implizite Gewaehrleistung der MARKTFAEHIGKEIT oder EIGNUNG FUER EINEN BESTIMMTEN ZWECK. Siehe die GNU General Public License fuer weitere Details.

Sie sollten eine Kopie der GNU General Public License zusammen mit diesem Programm erhalten haben. Falls nicht, siehe http://www.gnu.org/licenses/.

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.