+# tzpuFusionX
+
+**Website:** [engineers@work](https://eaw.app) | **Repository:** [git.eaw.app/eaw/tzpuFusionX](https://git.eaw.app/eaw/tzpuFusionX)
+
+---
+
+
## Overview
@@ -7,7 +13,7 @@ The tranZPUterFusionX is a spinoff concept from the tra
rapid application loading from SD card and by using a daughter board, better graphics and sound.
-The FusionX board can also be used to power alternative CPU's on the host for testing, development and to provide a completely different software platform and applications. It can use the underlying hosts keyboard, monitor, I/O and additionally better graphics and sound provided by the FusionX.
+The FusionX board can also be used to power alternative CPUs on the host for testing, development and to provide a completely different software platform and applications. It can use the underlying hosts keyboard, monitor, I/O and additionally better graphics and sound provided by the FusionX.
It shares similarities with the tranZPUterFusion but instead of realising it in hardware via an FPGA it realises
@@ -18,7 +24,7 @@ Using the same base design as the tranZPUterFusion it i
In Z80 configuration, a Linux Kernel driver instantiates a Z80 emulation which realises a Z80 CPU in software which in turn can command and control the host system. The kernel driver along with a controlling application
-can provide a wealth of features to the host through this mechanism. The SOM is also connected to an SD Drive and USB 2.0 port so there is no limit to features which can be proivded.
+can provide a wealth of features to the host through this mechanism. The SOM is also connected to an SD Drive and USB 2.0 port so there is no limit to features which can be provided.
Like the tranZPUterFusion, the tranZPUterFusionX can provide enhanced video and sound to the host. The SOM incorporates dual DAC audio and a 2D GPU with configurable resolutions switched onto the hosts video and audio outputs under software control.
@@ -27,8 +33,8 @@ Like the tranZPUterFusion, the tranZPUterFusionX board is ideal for any developer wanting to physically program and interact with retro hardware using a Linux platform with Wifi and USB/Serial port connectivity.
-To most retro users, in the early stages of FusionX development, the board wont have much use. As the project matures, a board can be obtained and installed into the Z80 socket of their Sharp or simlar Z80 based system (providing there is sufficient room to accommodate this board) and utilise the upgraded featues, such as:
-- Original host specifications
- the machine behaves just as though it had a physical Z80 within. There might be slight differences in the Z80 functionality as it is implemented in software but the Z80 hardware timing is accurate. - Accelerator
- the Z80 can run at much higher speeds due to the abundance of memory and 1.2GHz dual-core processor, which would typically see performance upto that of a 500MHz Z80. - Emulation
- emulation of all the Sharp MZ series machines, experiencing it through the host system keyboard, monitor and I/O.
@@ -82,13 +88,13 @@ thus the CPLD is able to drive 5V circuitry and with sufficient drive current, 2
The CPLD internal state machines are clocked by an external 50MHz oscillator, this allows for adequate sampling and state change for a typical 1MHz - 6MHz Z80 host.
-
+
Schematic 2 - I/O (Audio, UART, USB)
- Stereo Audio Microphone input
- a digital microphone input is also available but the pins are used in the CPLD interface. - Stereo Audio DAC output
- dual digital to analogue converters for sound output which can be clocked at 48KHz. - WiFi Antenna
- a SSW101B 20/40MHz IEEE 802.11 b/g/n/e/l/n/w WiFi transceiver operating in the 2.4GHz band with a 500M range. The SOM also includes a 100MHz ETH PHY but this is not used in this design as hard wired ethernet is not practical for a board which is @@ -97,12 +103,12 @@ sited inside a retro machine. - USB
- a Linux connected USB port allowing for device expansion, such as additional storage, mice etc. - Fast UART
- high speed full duplex with hardware handshake UART. - UART
- standard 2 pin UART operating upto 500KHz.
- - SD Card
- the SOM has inbuilt FlashNAND so can accomodate a simple Linux filesystem, addition of an SD card allows for greater storage of Host applications and Linux utilities. An SD card also makes for ease of upgrades as the SOM will auto upgrade when a suitably prepared SD card is present on boot.
+ - SD Card
- the SOM has inbuilt FlashNAND so can accommodate a simple Linux filesystem, addition of an SD card allows for greater storage of Host applications and Linux utilities. An SD card also makes for ease of upgrades as the SOM will auto upgrade when a suitably prepared SD card is present on boot. - Voltage level translation
— Bridges the 5V TTL Z80 host bus to the 3.3V LVTTL signals used by the SOM. The MAX7000AE is 5V tolerant on inputs and drives outputs at 3.3V, which exceeds the 2.4V switching threshold of 5V TTL receivers, giving up to 25mA drive per pin.
+ - Cycle-accurate Z80 bus timing
— The CPLD implements a hardware FSM clocked by a 50MHz external oscillator that samples the host Z80 clock and reproduces the precise T-state sequence for every bus cycle type. This offloads all critical timing from the SOM, which only needs to respond with data within the window defined by the CPLD FSM.
+ - SOM interface bridging
— Converts between the Z80 parallel bus protocol and the SPI + 8-bit GPIO interface used by the SOM kernel module, translating bus events into a format that the SSD202 can service efficiently from a Linux kernel thread.
+ - Video and audio switching
— Controls multiplexers that select between the host machine's native video/audio output and the SOM video/audio for routing to the monitor and speakers via daughter board connectors. Switching is commanded by the SOM over SPI.
+ - Video sync and clock generation
— Generates composite sync (VGA_CSYNCn) from the SOM VSync and HSync signals, detects blanking intervals, generates a 25MHz pixel clock for the monochrome DAC (by dividing the 50MHz oscillator), and produces a colour carrier frequency signal (VGA_COLR) for composite colour output.
+ - Reset management
— Monitors the host Z80 RESET line and implements a dual-press reset protocol: a single reset press asserts a soft reset to the SOM (allowing the Z80 application to reinitialise), while a second press within one second drives the SOMPM_RESETline to force a full SOM power-cycle reboot.
+ - USB power control
— Controls the USB VBUS power enable signal under SOM command.
+ - SPI slave (write path)
— A 4-wire SPI slave (VSOM_SPI_CLK,VSOM_SPI_MOSI,VSOM_SPI_MISO,VSOM_SPI_CSn) receives commands and data from the SOM. Up to 4 bytes per frame are shifted in via a serial shift register and decoded into bus control commands (memory write data, I/O write data, video/audio source selection, USB power control). The SPI clock polarity is parameterised (SPI_CLK_POLARITY) to accommodate different SOM SPI configurations.
+ - 8-bit parallel bus (read path)
— An 8-bit output bus (VSOM_DATA_OUT[7:0]) with aVSOM_HBYTEselect line presents either the low or high byte of the current Z80 address/data word to the SOM GPIO inputs. Additional single-bit status lines report:VSOM_READY(FSM idle),VSOM_LTSTATE(last T-state of current cycle),VSOM_BUSRQ,VSOM_BUSACK,VSOM_INT,VSOM_NMI,VSOM_WAIT, andVSOM_RESET.
+ ../tzpuFusionX_Toplevel.vhd— top-level entity instantiation and I/O pin definitions
+ ../tzpuFusionX_pkg.vhd— shared package (types, constants)
+ ../tzpuFusionX.vhd— main RTL architecture (FSMs, SPI, bus interface, video/audio control)
+- Connect the USB-Blaster to the FusionX JTAG header and the host PC. +
- Power the FusionX board (the CPLD must be powered during programming). +
- In Quartus II, open Tools → Programmer. +
- Load the chain description file:
build/output_files/tzpuFusionX_MZ80A.cdf.
+ - Verify the USB-Blaster is detected in the hardware list, then click Start. +
- Programming completes in a few seconds; the CPLD becomes active immediately on completion. +
- Linux OS
— Kernel 4.9-rt (PREEMPT_RT) with Buildroot root filesystem running on the SigmaStar SSD202 dual-core Cortex-A7.
+ - z80drv.ko
— Linux kernel module implementing the Z80 CPU emulator and host hardware interface. Runs the Z80 emulation loop on a dedicated CPU core.
+ - ttymzdrv.ko
— Linux TTY kernel module that presents the Sharp MZ keyboard and display as a standard Linux terminal device (/dev/ttymz0).
+ - z80ctrl
— User-space command-line utility for controlling the z80drv kernel module: load ROM images, add virtual hardware devices, start/stop emulation and inspect emulated memory.
+ - k64fcpu
— User-space daemon emulating a K64F virtual CPU. Used in TZFS mode to manage ROM loading and inter-processor communication with the Z80 emulator.
+ - sharpbiter
— Sharp MZ arbiter daemon, coordinating access to the shared Sharp MZ hardware resources between the Z80 emulator and the Linux TTY driver.
+ - RFS mode
(startZ80_RFS.sh) — loads the ROM Filing System virtual hardware device and starts the MZ-80A emulator with 40- or 80-column ROM images.
+ - TZFS mode
(startZ80_TZFS.sh) — loads the tranZPUter SW virtual hardware device and starts thek64fcpuK64F daemon which manages Monitor and TZFS ROM image loading.
+ - ttymzdrv.ko
— Linux TTY kernel module that maps the Sharp MZ keyboard and display to/dev/ttymz0. Supports suspend and resume, enabling the user to switch seamlessly between a Z80 session and a Linux console at the host machine without losing state in either.
+ - z80ctrl utility
— Command-line tool for runtime control of the Z80 emulator: loading ROM images, registering virtual hardware devices, starting and stopping the emulation loop, and inspecting emulated memory. Communicates withz80drv.kovia a kernel character device.
+ - k64fcpu daemon
— User-space daemon that emulates a K64F virtual CPU. Active in TZFS mode; it manages Monitor and TZFS ROM image loading into the emulator's memory space and relays inter-processor commands toz80drv.ko.
+ - sharpbiter daemon
— Sharp MZ arbiter; coordinates access to the shared Sharp MZ keyboard and display hardware between the TTY driver and the Z80 emulator so that both can operate without conflicting on the underlying I/O registers.
+ - WiFi and web server
— The SOM's integrated 802.11 b/g/n transceiver (SSW101B) provides network connectivity. A lightweight web server on CPU0 can serve configuration and status pages, and the WiFi stack handles OTA firmware delivery via SD card auto-upgrade on boot.
+ - Calls the Zeta Z80 CPU core for each instruction execution step +
- Dispatches each resulting memory or I/O access to the correct handler — physical host hardware, kernel-resident RAM image, or a virtual hardware module function +
- Drives the GPIO and SPI hardware via
z80io.cto assert or sample the Z80 bus signals through the CPLD
+ - Runs at 1.2GHz with the PREEMPT_RT kernel ensuring minimal interrupt jitter even from CPU0 activity +
- Voltage level translation
— The CPLD is 5V tolerant on its inputs and drives outputs at 3.3V Low Voltage TTL levels. Since the 5V TTL switching threshold is approximately 2.4V the CPLD can drive 5V host logic directly with up to 25mA per pin, making the board compatible with unmodified vintage Z80 hardware.
+ - Cycle-accurate Z80 bus timing
— The CPLD embeds state machines clocked by an external 50MHz oscillator. These state machines sample the Z80 host clock and reproduce the precise T-state sequence for each bus cycle (fetch, memory read/write, I/O read/write) as defined in the Z80 state diagrams. This means the SOM kernel module does not need to replicate sub-microsecond Z80 timing in software — the CPLD handles it in hardware.
+ - SPI channel (50MHz)
— used for writing data and commands to the CPLD. SPI write is used in preference to GPIO for host bus writes because it is clocked and therefore more reliable for multi-byte transfers at speed.
+ - 8-bit GPIO bus
— used byz80io.cfor reading bus status and address/data values from the CPLD. Direct register access is used (bypassing the SigmaStar HAL API after initialisation) to minimise read latency. The maximum read throughput achievable via the SSD202 GPIO structure is approximately 2MB/s for an 8-bit byte — fast enough to service Z80 bus cycles at typical host clock rates (1MHz–6MHz) when combined with the CPLD buffering.
+ - ARM cross-compiler:
arm-linux-gnueabihf-gcc(e.g. fromgcc-arm-linux-gnueabihfpackage)
+ - SigmaStar SDK source tree (kernel, U-boot, Buildroot) in the parent directory structure expected by
Build_FusionX.sh
+ - FusionX application source in the
../FusionXdirectory relative to the linux build directory
+ - Standard build tools:
make,cmake,bc,libssl-dev
+ - 2D06
— FusionX custom configuration using theinfinity2m_spinand_fusionx_defconfigkernel defconfig.
+ - 2D07
— Standard SigmaStar reference configuration usinginfinity2m_spinand_ssc011a_s01a_minigui_defconfig.
+ --adddev --device <name>— add a virtual hardware device (rfs, tzpu, mz700, mz80a, mz2000, pcw)
+ --start/--stop— start or stop the Z80 emulation loop
+ --loadrom --file <path> --addr <hex> --type <n>— load a ROM binary into emulated memory
+ --mem --addr <hex> --len <n>— inspect emulated memory contents
+ --cmd <hex>— send a command byte directly to the CPLD/Z80 gateway
+
The SOM is rich in peripherals and this circuit interfaces some of them for use in the FusionX, these include:
-
-
+
Schematic 3 - Video (VideoDAC, Contrast DAC)
@@ -117,7 +123,7 @@ DAC, as it is sending the video signal with colour information as a voltage cont
In order to get true black, the CPLD creates a blanking signal, MONO.BLANK, which is paired with a MUX 0V clamp on the daughter board which drives the monochrome monitor, this sees the RGB332 as 0V when 00000000 is present, then varying between 4.01V-5V when non-zero.
-
+
Schematic 4 - Power Supply (3.3V, USB)
@@ -128,7 +134,7 @@ The power supply, for the SOM and CPLD, converts the 5V present on the Z80 socke
Additionally, a software controlled USB power switch is installed to enable (and reset if required) +5V power to the USB expansion port.
-
+
Schematic 5 - CPLD Interface
@@ -136,70 +142,490 @@ Additionally, a software controlled USB power switch is installed to enable (and
The final schematic is the interface between the SOM and the CPLD. Originally this was going to be a bi-directional 16bit bus with Read/Write and Strobe signals but after testing, the setup time for a 16bit signal with tri-state switching was much slower than an SPI connection
due to the GPIO register layout and operation within the SOM and the speed of the I/O operations within the SOM.
-The solution used is to have a bidirectional 72MHz SPI bus between the SOM and CPLD for transmitting Z80 transaction requests and an 8bit read only parallel bus for more rapid reading of Z80 Data and seperate Z80 state information.
+The solution used is to have a bidirectional 72MHz SPI bus between the SOM and CPLD for transmitting Z80 transaction requests and an 8bit read only parallel bus for more rapid reading of Z80 Data and separate Z80 state information.
-
+
-#### PCB
+#### PCB
-
+
The PCB was designed with minimum size as a primary requirement for the various machines in which it would be installed. It also had to be compatible with the tranZPUterFusion for interchangeability.
-A major concern was heat dissipation as the PCB, when installed within an MZ-700 is very close to existing motherboard components which give off a lot of heat with no air circulation in a sealed compact housing. This meant active components couldnt be sited on the PCB underside
+A major concern was heat dissipation as the PCB, when installed within an MZ-700 is very close to existing motherboard components which give off a lot of heat with no air circulation in a sealed compact housing. This meant active components couldn't be sited on the PCB underside
as heat generation would lead to instability and failure, which in turn led to an increase in the final PCB size.
-The smallest components which could be manually assembled where used, ie. 0402/0603 passive devices and 0.5mm IC pitch spacing to reduce overall size and a 4 layer stackup selected to fit all required components.
+The smallest components which could be manually assembled were used, ie. 0402/0603 passive devices and 0.5mm IC pitch spacing to reduce overall size and a 4 layer stackup selected to fit all required components.
PCB Top Overview
-
+
PCB Bottom Overview
-
+
PCB 4 Layer Routing Overview
-
+
PCB Assembled
-
+
-
+
PCB Component Placement and Bill of Materials
-Click here to view an interactive PCB component placement diagram and Bill of Materials.
+Click here to view an interactive PCB component placement diagram and Bill of Materials.
+
+
+--------------------------------------------------------------------------------------------------------
+
+
+###### CPLD
+
+
+The tranZPUterFusionX uses an Altera MAX7000AE CPLD — specifically the EPM7512AETC144-10 — as the central interface between the SOM and the host Z80 socket. This is a 512-macrocell, 144-pin TQFP device operating at 3.3V LVTTL on its outputs while accepting 5V TTL levels on its inputs, making it directly compatible with vintage Sharp MZ and other Z80-based hardware without any additional level shifting.
+
+
+The CPLD design is written in VHDL and built with Altera Quartus II 13.0.1 SP1 (Web Edition). Because each host machine has slightly different bus timing requirements and memory map constraints, a separate VHDL implementation is maintained for each supported host:
+
+
+
+| VHDL Variant | Host Machine | Directory |
+|---|---|---|
+| `tzpuFusionX.vhd` (MZ80A) | Sharp MZ-80A | `CPLD/v1.0/MZ80A/` |
+| `tzpuFusionX.vhd` (MZ700) | Sharp MZ-700 | `CPLD/v1.0/MZ700/` |
+| `tzpuFusionX.vhd` (MZ2000) | Sharp MZ-2000 | `CPLD/v1.0/MZ2000/` |
+| `tzpuFusionX.vhd` (PCW8256) | Amstrad PCW-8256 | `CPLD/v1.0/PCW8256/` |
+
+
+
+Purpose and Role
+
+
+The CPLD performs several functions that would be impractical or impossible to implement directly in software on the SOM:
+
+
+
+
+Z80 Bus FSM
+
+-
+
+The heart of the CPLD design is a finite state machine (
+
+
+| FSM State | Z80 Bus Cycle | Description |
+|---|---|---|
+| `IdleCycle` | — | Bus is idle; waiting for MREQ or IORQ assertion. |
+| `FetchCycle` | Opcode Fetch (M1) | M1 + MREQ + RD active; address and data phases timed across T1–T3. |
+| `RefreshCycle` | DRAM Refresh | RFSH + MREQ active; lower 7 bits of address presented for DRAM row refresh. |
+| `ReadCycle` | Memory Read | MREQ + RD active; address presented T1, data sampled T3. |
+| `WriteCycle` | Memory Write | MREQ + WR active; address and data presented T1–T2, write strobed T3. |
+| `ReadIOCycle` | I/O Read | IORQ + RD active; I/O address and data phases with WAIT support. |
+| `WriteIOCycle` | I/O Write | IORQ + WR active; I/O address and data presented with WAIT support. |
+| `HaltCycle` | HALT | Z80 HALT assertion detected; repeated NOP fetch cycles suppressed. |
+| `BusReqCycle` | Bus Request | BUSRQ asserted; BUSACK driven, bus lines tri-stated, SOM notified. |
+
+SOMFSMState) that tracks and reproduces the Z80 bus cycle state at 50MHz resolution. The FSM monitors the host Z80 clock edges and the bus control signals (MREQ, IORQ, RD, WR, M1, RFSH, BUSRQ, HALT, WAIT) to classify each bus cycle and step through the correct T-state sequence:
+
+
+
+Each state has numbered sub-states (e.g.
+
+
+
+SOM Interface
+
+FetchCycle_11, FetchCycle_20) corresponding to individual half-cycles within the T-state, allowing the CPLD to assert or deassert control signals with sub-clock-cycle precision relative to the host CLK edges.
+
+
+A secondary CTRLFSMState FSM handles SPI command processing (CTRLCMD_Idle → CTRLCMD_ReadIOWrite) independently of the main bus cycle FSM, so that SPI transactions from the SOM do not block Z80 bus cycle servicing.
+
+The CPLD presents two distinct interfaces to the SOM:
+
+
+
+
+Building the CPLD Image
+
+-
+
+The CPLD bitstream is produced using Altera Quartus II 13.0.1 SP1 Web Edition, which is available as a free download from the Intel FPGA (formerly Altera) website. The Web Edition supports all MAX7000AE devices and is sufficient for this project.
+
+
+Opening the Project
+ +Each host machine variant has its own Quartus project in the corresponding subdirectory. To build the MZ-80A variant, for example: + +
+ +In the Quartus GUI select Processing → Start Compilation (or press Ctrl+L). The tool runs Analysis & Synthesis, Fitter, Assembler and Timing Analysis in sequence. A successful build produces: + +
+ +Programming is performed via JTAG using an Altera USB-Blaster or compatible JTAG adapter connected to the 10-pin JTAG header on the FusionX board: +
--------------------------------------------------------------------------------------------------------
## Software
-Under construction.
++ +Each host machine variant has its own Quartus project in the corresponding subdirectory. To build the MZ-80A variant, for example: + +
# Open in Quartus II GUI: +File -> Open Project -> CPLD/v1.0/MZ80A/build/tzpuFusionX_MZ80A.qpf + +# Or launch from the command line using the Quartus shell: +quartus_sh --flow compile tzpuFusionX_MZ80A ++ +The project references three VHDL source files (paths relative to the project
build/ directory):
+-
+
+ +In the Quartus GUI select Processing → Start Compilation (or press Ctrl+L). The tool runs Analysis & Synthesis, Fitter, Assembler and Timing Analysis in sequence. A successful build produces: + +
build/output_files/tzpuFusionX_MZ80A.pof # Programmer Object File (JTAG programming) +build/output_files/tzpuFusionX_MZ80A.fit.rpt # Fitter report (resource usage) +build/output_files/tzpuFusionX_MZ80A.sta.rpt # Timing analysis report ++ +The
.pof file is the binary image used to program the physical CPLD device.
+
+
+Programming the CPLD+ +Programming is performed via JTAG using an Altera USB-Blaster or compatible JTAG adapter connected to the 10-pin JTAG header on the FusionX board: +
-
+
+The FusionX software stack spans from the Linux operating system through to dedicated kernel modules and user-space utilities. The complete software set is built using a customised SigmaStar build environment and loaded onto the SOM's SPI NAND flash. On boot, U-boot initialises the SOM and hands off to the Linux kernel, which loads the Buildroot root filesystem. The FusionX startup script then configures the system and brings the Z80 emulator online.
+
+
+The software components are:
+
+
+
+
+###### Architecture
+
+-
+
start_FusionX.sh, which loads ttymzdrv.ko, starts a getty login session on /dev/ttymz0, pins all Linux processes and IRQs to CPU0, loads z80drv.ko onto the isolated CPU1, then launches the k64fcpu and sharpbiter daemons. Two pre-built startup modes are provided:
+-
+
+The FusionX software architecture is layered, with each layer handling a distinct responsibility. From the host machine's perspective the flow is entirely transparent — the Z80 socket behaves as a normal Z80 CPU while the SOM is silently intercepting and emulating every bus cycle.
+
+
+
+
+
+
+Dual-Core Design
+
++ 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) || + | +--------------------------------------+| + +------------------------------------------+ ++
+The SSD202's two Cortex-A7 cores operate under a strict separation of responsibility. At startup every Linux process and every hardware IRQ affinity is migrated to CPU0, leaving CPU1 exclusively available to the Z80 emulation kernel thread. The CPU frequency governor is set to performance mode (1.2GHz fixed) after the emulator starts to prevent frequency-scaling transitions from introducing timing variation in the emulation loop.
+
+
+CPU0 — Linux and User-Space Services
+Runs the complete Linux 4.9-rt operating system, all user-space daemons and handles all hardware interrupts. Key responsibilities on CPU0 include: +
+Exclusively runs the
+
+
+
+CPLD Bus Interface
+
++Runs the complete Linux 4.9-rt operating system, all user-space daemons and handles all hardware interrupts. Key responsibilities on CPU0 include: +
-
+
+Exclusively runs the
kthread_z80 kernel thread spawned by z80drv.ko. No other process or interrupt is ever scheduled on CPU1 after initialisation. The emulation loop on CPU1:
+-
+
+The hardware path from the SOM to the Z80 host socket passes through an Altera MAX 7000A CPLD. This device serves two essential roles:
+
+
+
+
+Memory Architecture
+
+-
+
-
+
PHYSICAL-type block is encountered (e.g. for host video RAM or hardware registers that must be accessed on the real hardware).
+
+The 128MB DRAM on the SSD202 SOM is shared between the Linux operating system and the Z80 kernel module. The kernel module allocates a contiguous region of physically-addressed kernel memory to hold ROM and RAM images for the emulated Z80. This region is accessed directly by the
+
+
+| Type | Description |
+|------|-------------|
+| `kernel RAM` | Read/write region backed by a kernel-allocated DRAM buffer. Standard RAM for the emulated machine. |
+| `kernel ROM` | Read-only region in kernel DRAM. Write cycles are silently discarded. Used for Monitor ROMs, BASIC ROMs, User ROMs, TZFS ROM pages. |
+| `PHYSICAL` | Pass-through to real host hardware — the SOM releases the CPLD bus and the host hardware responds to the cycle directly. Used for host video RAM and I/O registers that must interact with real hardware. |
+| `VIRTUAL` | Each access triggers a C handler function within the kernel module. Used to emulate peripheral devices (floppy controller, QuickDisk, RFS banking logic) without any real hardware. |
+
+kthread_z80 running on CPU1, with no virtual memory translation overhead in the inner emulation loop.
+
+
+The emulated Z80 sees a configurable memory map across the standard 64KB (0x0000–0xFFFF) address space. Each region is assigned one of the following access types:
+
+
+
+ROM images are loaded into kernel memory at startup by
+
+
+
+Virtual Hardware Modules
+
+z80ctrl --loadrom (or automatically by the active virtual hardware module or the k64fcpu daemon in TZFS mode). Multiple ROM page sets can be resident simultaneously — the RFS virtual hardware module, for example, maintains up to four switchable ROM pages (MROM, User ROM I/II/III) for 40-column and 80-column configurations.
+
+
+Machine timing constants for each supported host (MZ-80A, MZ-700, MZ-2000, PCW-8256) are defined in z80driver.h and used by the emulation loop to pace bus cycles at the correct rate relative to the host clock, ensuring that time-sensitive software (tape motor control, serial I/O, delay loops) behaves as it would on original hardware.
+
+Virtual hardware modules are C source files (
+
+
+| Module | Host | Role |
+|--------|------|------|
+| `z80vhw_mz80a.c` | Sharp MZ-80A | Original MZ-80A memory map, keyboard matrix and display I/O — no extensions. |
+| `z80vhw_mz700.c` | Sharp MZ-700 | MZ-700 bank-switching, video and keyboard I/O emulation. |
+| `z80vhw_mz2000.c` | Sharp MZ-2000 | MZ-2000 memory map, extended video modes and I/O. |
+| `z80vhw_pcw.c` | Amstrad PCW-8256 | PCW-8256 memory/bank paging and peripheral I/O. |
+| `z80vhw_rfs.c` | MZ-80A + RFS board | ROM Filing System: manages four switchable ROM pages (40-col and 80-col sets), SD-based MZF program loading, bank switching. |
+| `z80vhw_tzpu.c` | MZ-80A + tranZPUter SW | tranZPUter SW virtual hardware; the kernel-side driver works with the userspace z80vhw_*.c) that define the behaviour of a specific host machine or peripheral set. Rather than being compiled as separately-linked objects they are #included directly into z80driver.c, so their handler functions are inlined into the emulation dispatch path with no function-call overhead.
+
+
+Up to five virtual hardware devices can be active simultaneously (MAX_VIRTUAL_DEVICES 5). Devices are registered at runtime before the emulator starts using z80ctrl --adddev --device <name>. Each registered device receives memory read, memory write, I/O read and I/O write callbacks for the address ranges it claims, and can optionally install its own ROM images and configure the memory map during initialisation.
+
+
+The available modules and the host machines they support are:
+k64fcpu daemon to provide K64F virtual CPU behaviour, TZFS ROM page management and CP/M support. |
+
+
+
+
+The TZPU module (
+
+
+
+###### Build
+
+z80vhw_tzpu.c) is architecturally distinct from the others. Because the K64F co-processor behaviour is complex and stateful, it is split across two components: the z80vhw_tzpu.c kernel-side stub handles fast bus-cycle dispatch while the k64fcpu user-space daemon on CPU0 manages ROM loading, memory bank selection and higher-level K64F command processing. The two halves communicate via a shared memory region in the kernel module.
+
+The complete FusionX OS and application set is built using the
+
###### Linux
-Under construction.
+Build_FusionX.sh script, which wraps the SigmaStar SDK build system and produces a ready-to-flash NAND image. Building requires a Linux host with the ARM cross-compiler toolchain installed.
+
+
+Prerequisites
+-
+
software/linux/ directory:
+
+# Build full image for FusionX (project 2D06, SPI NAND, SSD202, 256MB flash) +./Build_FusionX.sh -f nand -p ssd202 -o 2D06 -m 256 ++ +This builds in sequence: U-boot bootloader, Linux kernel (using the FusionX custom defconfig
infinity2m_spinand_fusionx_defconfig), Buildroot root filesystem and the FusionX application set. Output images are written to project/image/output/images/.
+
+For the standard SigmaStar reference configuration use project 2D07 instead.
+
+
+
+Building Kernel Modules Only
+
+The kernel modules can be rebuilt independently against an already-built kernel tree, which is useful during development:
+
+# Build z80drv kernel module +cd software/FusionX/src/z80drv/src.mz80a +make + +# Build ttymzdrv kernel module +cd software/FusionX/src/ttymz +make ++ +The resulting
z80drv.ko and ttymzdrv.ko files can be copied directly to the /apps/FusionX/modules/ directory on the running SOM (via SSH or SD card) and loaded with insmod.
+
+
+
+Flashing and Updates
+
+The flash image produced by the build script is programmed to the SOM SPI NAND via the SigmaStar ISP tool over USB. Once the initial image is installed, subsequent updates can be delivered via SD card — when the SOM boots with a suitably prepared SD card present it will auto-upgrade the NAND image without requiring a USB connection.
+
+The Linux platform runs on the SigmaStar SSD202 (Infinity2M) SOM — a 29mm × 29mm stamp module containing a dual-core ARM Cortex-A7 at 1.2GHz, 128MB DRAM, 256MB SPI NAND flash and an integrated 802.11 b/g/n WiFi transceiver. The kernel is Linux 4.9 with the PREEMPT_RT real-time patch applied to minimise scheduling latency, which is essential for responsive Z80 emulation.
+
+
+The complete OS image — U-boot bootloader, Linux kernel, Buildroot root filesystem and FusionX application set — is assembled using the
+
###### Z80 Emulator
-Under construction.
+Build_FusionX.sh script, a customised version of the SigmaStar SDK build system. Two project targets are defined:
+-
+
Build_FusionX.sh -f nand -p ssd202 -o 2D06 -m 256 and produces a full flash image ready for programming to the SOM NAND.
+
+
+A key aspect of the Linux configuration is CPU isolation. At startup all Linux processes and hardware IRQs are migrated to CPU0. CPU1 is then dedicated exclusively to the kthread_z80 kernel thread which runs the Z80 emulation loop. This CPU affinity separation, combined with the PREEMPT_RT kernel, gives the Z80 emulator the most consistent and lowest-latency access to the host hardware interface. The CPU performance governor is also set to maximum frequency (1.2GHz) after the Z80 emulator is running to avoid frequency scaling causing timing variation in the emulation loop.
+
+
+The root filesystem is a Buildroot-based minimal Linux environment stored in the SOM NAND flash. An optional SD card can extend storage for Sharp MZ application software, ROM images and additional Linux utilities. When a suitably prepared SD card is present at boot the SOM will auto-upgrade from it, simplifying firmware updates.
+
+The Z80 emulator is implemented as a Linux kernel module,
+
+
+
+
+
+The virtual hardware modules are compiled inline into
--------------------------------------------------------------------------------------------------------
## Daughter Boards
z80drv.ko (v1.4, April 2023). It uses the Zeta Z80 CPU emulator library by Manuel Sainz de Baranda y Goñi as its Z80 instruction-set core, wrapped in a kernel-space driver that interfaces with the SSD202 GPIO hardware and the CPLD Z80 host interface.
+
+
+The hardware path from the SOM to the Z80 host socket runs: SSD202 GPIO / SPI → CPLD → Z80 DIP-40 socket. The CPLD handles accurate Z80 bus timing using a 50MHz clock, so the kernel module does not need to reproduce precise T-state timing itself. The GPIO interface is managed by z80io.c, which calls the SigmaStar HAL for initialisation but accesses registers directly for bit-level read/write operations to minimise latency. The practical read throughput of the SSD202 GPIO structure is approximately 2MB/s for an 8-bit byte, which means programs execute from emulated (kernel) memory rather than from the physical host memory over the bus.
+
+
+The emulator supports the following host machines, each with its own virtual hardware module:
+| Virtual Hardware Module | +Host Machine | +Description | +
|---|---|---|
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 |
z80drv.ko rather than linked as separate objects, which eliminates function call overhead in the emulation hot path. Up to five virtual hardware devices can be active simultaneously (MAX_VIRTUAL_DEVICES 5). Devices are added at runtime using z80ctrl --adddev --device <name> before starting the emulator.
+
+
+The z80ctrl utility provides full runtime control of the emulator from the Linux command line:
+-
+
ttymzdrv.ko module (ttymz.c, v1.2, July 2023) provides a standard Linux TTY interface on /dev/ttymz0 backed by the Sharp MZ keyboard and display hardware. This allows the host machine's console to be used as a Linux terminal — running a getty login session — while also supporting suspend and resume to switch the display between Linux and the Z80 emulation session without losing state. Supported hosts are MZ-80A, MZ-700 and MZ-2000.
+
-The tranZPUter series was initially developed in the Sharp MZ-80A and was primarily a Z80 replacement. As the concept evolved and the tranZPUter SW-700 was developed for the MZ-700 it became more of an integral component of the machine, offering original and upgraded Video and Audio capabilites by intercepting and routing existing signals.
+The tranZPUter series was initially developed in the Sharp MZ-80A and was primarily a Z80 replacement. As the concept evolved and the tranZPUter SW-700 was developed for the MZ-700 it became more of an integral component of the machine, offering original and upgraded Video and Audio capabilities by intercepting and routing existing signals.
After significant developments on the tranZPUter SW-700 it became desirable to port it back to the MZ-80A and MZ-2000 but these machines had different CPU orientation and signal requirements, ie. driving an internal and external monitor. This requirement led to the concept of daughter boards, where a specific board would be designed and developed for
@@ -207,7 +633,7 @@ the target host and would plug into the tranZPUter SW-700 card. Ideally I wanted
During the design of the tranZPUterFusionX one of the main requirements was to make the board small, the Z80 orientation changeable and also compatible with the tranZPUterFusion so that it could fit many machines and be interchangeable. As the SW-700 also interfaced to the Video and Audio of the machines
-and each was quite different, it became apparent that the tranZPUterFusionX needed to include a concept to allow different video/audio interfaces according to the targetted host. This concept was realised via daughter boards. Two connectors would link the tranZPUterFusionX to a daughter board which would be
+and each was quite different, it became apparent that the tranZPUterFusionX needed to include a concept to allow different video/audio interfaces according to the targeted host. This concept was realised via daughter boards. Two connectors would link the tranZPUterFusionX to a daughter board which would be
specifically designed for the intended host.
@@ -226,7 +652,7 @@ The purpose of the MZ-700 daughter board is to interface the video/audio circuit
is switched between the MZ-700 and FusionX under control of the FusionX.
-The original sound circuity of the MZ-700 drives a speaker directly and in order to inject FusionX audio into the MZ-700 speaker, the mainboard speaker output is routed to the daughter board, level converted and switched under control of the FusionX. The FusionX offers stereo sound so this is selectively switched/mixed with the
+The original sound circuitry of the MZ-700 drives a speaker directly and in order to inject FusionX audio into the MZ-700 speaker, the mainboard speaker output is routed to the daughter board, level converted and switched under control of the FusionX. The FusionX offers stereo sound so this is selectively switched/mixed with the
original MZ-700 sound and fed to a Class D amplifier which then drives the internal speaker. Line level stereo output is achieved via an additional 4pin connector and used as required.
@@ -241,7 +667,7 @@ This setup allows for Linux or emulated machines, whilst running as an applicati
The MZ-700 daughter board consists of three 4way SPDT analogue switches to route video and audio signals under FusionX control and a Class D power amplifier.
-
+
MZ-700 Video Interface PCB
@@ -251,16 +677,16 @@ The MZ-700 daughter board PCB is small and compact due to the space restrictions
- 
+ 
+
- 
+ 
+
- 
+ 
+
-The MZ-2000 daughter board PCB is small and compact due to the space restrictions and the number of connectors it must carry. It plugs into the mainboard monitor/IPL male connectors and then presents new CRT monitor, external Video and IPL/RESET switch connectors for all the exising internal cabling.
+The MZ-2000 daughter board PCB is small and compact due to the space restrictions and the number of connectors it must carry. It plugs into the mainboard monitor/IPL male connectors and then presents new CRT monitor, external Video and IPL/RESET switch connectors for all the existing internal cabling.
- 
+ 
+
- 
+ 
+
- 
+ 
+
-The purpose of the MZ-80A daughter board is to interface the video/audio/reset circuits of the FusionX board with those of the MZ-80A. The MZ-80A has an internal monochrome CRT, cutouts for and external RGB video socket and internal Audio with an amplifier on the monochrome CRT control board.
+The purpose of the MZ-80A daughter board is to interface the video/audio/reset circuits of the FusionX board with those of the MZ-80A. The MZ-80A has an internal monochrome CRT, cutouts for an external RGB video socket and internal Audio with an amplifier on the monochrome CRT control board.
The daughter board is designed to plug into the vertical mainboard CRT video connector with a gap so that the data cassette connector can be simultaneously connected. The gap is necessary as the CRT video connector sits close to the rear sidewall so the daughter board must extend forwards towards the keyboard.
@@ -332,7 +758,7 @@ The daughter board is designed to plug into the vertical mainboard CRT video con
It presents all the required connectors to connect the RESET switch (both in and out), internal monitor and external monitor on the same board.
-The RESET input is intercepted on the daughter board and sent to the FusionX. Technically it isnt needed as the FusionX samples the Z80 Reset which is based on this input, but it can be useful, for example, detecting requests to reboot the SOM (double press) rather than the MZ-80A circuitry.
+The RESET input is intercepted on the daughter board and sent to the FusionX. Technically it isn't needed as the FusionX samples the Z80 Reset which is based on this input, but it can be useful, for example, detecting requests to reboot the SOM (double press) rather than the MZ-80A circuitry.
The video signals from the mainboard are switched with the FusionX video monochrome signals and sent to the internal CRT monitor. This allows for original video output on the CRT monitor or advanced FusionX text and graphics, resolution subject to the timing constraints of the monitor.
@@ -341,7 +767,7 @@ The video signals from the mainboard are switched with the FusionX video
The FusionX RGB output is routed to the MZ-80A external RGB video socket (if installed) allowing for upto full HD external colour video display.
-The sound circuity of the MZ-80A is sent to an audio amplifier on the CRT monitor. This signal is intercepted and switched with the FusionX audio which then drives the CRT monitor amplifier. Line level stereo output is achieved via an additional 4pin connector and used as required.
+The sound circuitry of the MZ-80A is sent to an audio amplifier on the CRT monitor. This signal is intercepted and switched with the FusionX audio which then drives the CRT monitor amplifier. Line level stereo output is achieved via an additional 4pin connector and used as required.
@@ -352,20 +778,20 @@ The sound circuity of the MZ-80A is sent to an audio amplifier on the CRT monito
The MZ-80A daughter board consists of two 4way SPDT analogue switches to route video and audio signals under FusionX control. One SPDT switch is used for creating pure black in the modified video signal generated on the FusionX board.
-
+
MZ-80A Video Interface PCB
-The MZ-80A daughter board PCB is small and compact with a large punchout to enable connection with the mainboard CRT connector and thru connection of the data cassette signal connector. It plugs into the mainboard CRT monitor connector and then presents new CRT monitor, external Video and RESET In/Out switch connectors to be used with all the exising internal cabling.
+The MZ-80A daughter board PCB is small and compact with a large punchout to enable connection with the mainboard CRT connector and thru connection of the data cassette signal connector. It plugs into the mainboard CRT monitor connector and then presents new CRT monitor, external Video and RESET In/Out switch connectors to be used with all the existing internal cabling.
- 
+ 
+
- 
+ 
+
@@ -384,6 +810,17 @@ The table below contains all the sites referenced in the design and programming
+