# tzpuFusionX **Website:** [engineers@work](https://eaw.app) | **Repository:** [git.eaw.app/eaw/tzpuFusionX](https://git.eaw.app/eaw/tzpuFusionX) --- ## Overview
The tranZPUterFusionX is a spinoff concept from the tranZPUter series. It shares the same purpose, to replace the physical Z80 in a Sharp or similar system and provide it with features such as faster CPU, more memory, virtual devices, 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 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 it in software as an application. This is made possible by a SOM (System On a Module), not much bigger than an FPGA device yet provides an abundance of features, ie. dual-core 1.2GHz Cortex-A7 ARM CPU, 128MB RAM, 256MB FlashRAM, Wifi, HD Video, SD Card, USB port and runs the Linux operating system.
Using the same base design as the tranZPUterFusion it incorporates a CPLD to interface the Z80 host to the SOM and provide cycle accurate Z80 timing. The SOM interfaces to the CPLD via a 72MHz SPI channel and an 8bit bus to query signal status and initiate Z80 transactions.
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 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.
The FusionX 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 won't have much use. As the project matures, a board can be obtained and installed into the Z80 socket of their Sharp or similar Z80 based system (providing there is sufficient room to accommodate this board) and utilise the upgraded features, such as:
-------------------------------------------------------------------------------------------------------- ## Hardware
Version 1.0 is the first official release of the tranZPUterFusionX design.
The FusionX board builds on a tried and tested Z80 host interface using the Altera 7000A MAX CPLD device. The CPLD not only interfaces the 5V Z80 host signals to the 3.3V signals on more recent devices, it also embeds the logic to perform accurate Z80 timing using a 50MHz clock to sample the Z80 host clock and activate signals according to the published Z80 state diagrams.
In addition the FusionX includes a SigmaStar System-On-a-Module, this is a small 29mmx29mm stamp device which incorporates a dual-core Cortex-A7 CPU, 128MByte DRAM, 256MBytes FlashNAND and a Wifi transceiver. The SigmaStar SOM is capable of outputting 2D Graphics in an RGB 888 format with selectable resolution upto HD format. It is also capable of stereo audio DAC output at 48KHz. Click to view the full SigmaStar product brief.
Using the experience gathered on the tranZPUter SW-700, a 30bit Video DAC is chosen to render the SigmaStar SOM video rather than a 2R-R ladder and additionally an 8bit DAC is included for rendering monochrome monitor contrast levels to cater for colour shading on monochrome CRT monitors as found in the MZ-80A/MZ-2000.
The hardware design centers on a main circuit board which holds all the primary circuitry and a number of daughter boards, each daughter board dedicated to one host (ie. MZ-700, MZ-80A, MZ-2000). The daughter board intercepts the host video/audio subsystem and supports switching of the host video/audio and the mainboard video/audio to the monitor/speaker of the host. The mainboard can be used without daughter boards, the latter are only used when the SOM Video/Audio is required.
This section outlines the mainboard schematics and circuit board design of the tranZPUterFusionX.
## Schematics
Schematic 1 - Z80 Host socket to CPLD
The schematic interfaces the Z80 to the CPLD. The CPLD is 5V tolerant and operates internally at 3.3V. The outputs are selected as Low Voltage TTL meaning a '1' is represented by 3.3V as opposed to 5V in the host system. The specifications of 5V TTL see the switching threshold at approx 2.4V, thus the CPLD is able to drive 5V circuitry and with sufficient drive current, 25mA per pin.
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.
![FusionX Schematic2](../images/tzpuFusionX_v1_0_Schematics-2.png) Schematic 2 - I/O (Audio, UART, USB)
The SOM is rich in peripherals and this circuit interfaces some of them for use in the FusionX, these include:
![FusionX Schematic2](../images/tzpuFusionX_v1_0_Schematics-3.png) Schematic 3 - Video (VideoDAC, Contrast DAC)
The SOM outputs TTL RGB with 8bits per colour. This is interfaced to a 30bit VideoDAC with the lowest 2 bits, per colour, controlled by the CPLD.
In addition, in order to drive the internal monochrome monitors of the Sharp MZ-80A/MZ-80B/MZ-2000 an 8bit VideoDAC is added which outputs a video signal in the range 4V-5V using a 332 RGB colour input, the colour input being the MSB of the SOM 888 TTL output. I term this the Contrast DAC, as it is sending the video signal with colour information as a voltage controlled contrast signal which presents itself on the monitor as differing contrast levels, thus simulating colour as grey levels.
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.
![FusionX Schematic4](../images/tzpuFusionX_v1_0_Schematics-4.png) Schematic 4 - Power Supply (3.3V, USB)
The power supply, for the SOM and CPLD, converts the 5V present on the Z80 socket into 3.3V using a high efficiency buck converter. This is necessary to minimise heat and provide maximum current to the SOM/CPLD.
Additionally, a software controlled USB power switch is installed to enable (and reset if required) +5V power to the USB expansion port.
![FusionX Schematic5](../images/tzpuFusionX_v1_0_Schematics-5.png) Schematic 5 - CPLD Interface
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 separate Z80 state information.
![FusionX Schematic6](../images/tzpuFusionX_v1_0_Schematics-6.png) #### 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 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 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 ![FusionX PCB Top](../images/tzpuFusionX_v1_0_3D_Top.png) PCB Bottom Overview ![FusionX PCB Bottom](../images/tzpuFusionX_v1_0_3D_Bottom.png) PCB 4 Layer Routing Overview ![FusionX Routing](../images/tzpuFusionX_v1_0_layout.png) PCB Assembled ![FusionX Assembled](../images/FusionX_Top.png) ![FusionX Assembled](../images/FusionX_Bottom.png) PCB Component Placement 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 (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:
| 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. |
Each state has numbered sub-states (e.g. 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.
SOM Interface
The CPLD presents two distinct interfaces to the SOM: This split architecture — SPI for writes, GPIO parallel bus for reads — matches the relative performance characteristics of the SSD202: SPI is clocked and reliable for multi-byte writes, while GPIO direct register access gives the lowest possible read latency for sampling bus state within a Z80 T-state window.
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: 
# 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): Compilation
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:
  1. Connect the USB-Blaster to the FusionX JTAG header and the host PC.
  2. Power the FusionX board (the CPLD must be powered during programming).
  3. In Quartus II, open Tools → Programmer.
  4. Load the chain description file: build/output_files/tzpuFusionX_MZ80A.cdf.
  5. Verify the USB-Blaster is detected in the hardware list, then click Start.
  6. Programming completes in a few seconds; the CPLD becomes active immediately on completion.
The CPLD retains its programmed logic indefinitely without power (MAX7000AE uses EEPROM-based configuration cells) so the device only needs to be programmed once per build or when updating to a new bitstream.
-------------------------------------------------------------------------------------------------------- ## Software
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: Startup is handled by 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:
###### Architecture
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. 
 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)            ||
 |  +--------------------------------------+|
 +------------------------------------------+
Dual-Core Design
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: CPU1 — Z80 Emulator (dedicated)
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:
CPLD Bus Interface
The hardware path from the SOM to the Z80 host socket passes through an Altera MAX 7000A CPLD. This device serves two essential roles: The SOM communicates with the CPLD through two parallel channels: Because the GPIO read throughput sets an upper bound on bus transaction rate, Z80 programs execute from kernel-resident memory images rather than being read from the physical host memory bus on every access. ROM images are loaded into kernel memory at startup, and all memory accesses by the emulated Z80 are serviced from there — the physical host bus is only engaged when a PHYSICAL-type block is encountered (e.g. for host video RAM or hardware registers that must be accessed on the real hardware).
Memory Architecture
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 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:
| 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. |
ROM images are loaded into kernel memory at startup by 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
Virtual hardware modules are C source files (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:
| 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 k64fcpu daemon to provide K64F virtual CPU behaviour, TZFS ROM page management and CP/M support. |
The TZPU module (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.
###### Build
The complete FusionX OS and application set is built using the 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 Building the Full OS Image The build is launched from the 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.
###### Linux
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 Build_FusionX.sh script, a customised version of the SigmaStar SDK build system. Two project targets are defined: The build script is invoked as: 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.
###### Z80 Emulator
The Z80 emulator is implemented as a Linux kernel module, 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.cSharp MZ-80AOriginal MZ-80A behaviour, no additions
z80vhw_mz700.cSharp MZ-700Original MZ-700 behaviour, no additions
z80vhw_mz2000.cSharp MZ-2000MZ-2000 emulation
z80vhw_pcw.cAmstrad PCW-8256PCW-8256 emulation
z80vhw_rfs.cMZ-80A + RFSROM Filing System virtual hardware for MZ-80A
z80vhw_tzpu.cMZ-80A + tranZPUter SWtranZPUter SW virtual hardware; combines kernel driver with userspace k64fcpu daemon
The virtual hardware modules are compiled inline into 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:
The 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.
-------------------------------------------------------------------------------------------------------- ## Daughter Boards
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 the target host and would plug into the tranZPUter SW-700 card. Ideally I wanted to port the SW-700 to an MZ-800/MZ-1500 and X1 but the size of the card and orientation of the Z80 was a limitation.
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 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.
The daughter boards would be responsible for switching and mixing video/audio signals and to drive internal monitors and provide the correct input and output connectors for ease of installation.
Currently three daughter boards have been developed, for the MZ-700, MZ-80A and MZ-2000 and more will follow as the design progresses.
-------------------------------------------------------------------------------------------------------- ###### MZ-700 Daughter Board
The purpose of the MZ-700 daughter board is to interface the video/audio circuits of the FusionX board with those of the MZ-700. It is designed to be inserted into the mainboard modulator output and the modulator connector in turn connected to the daughter board. This allows the MZ-700 to be used with a standard monitor and the video output is switched between the MZ-700 and FusionX under control of the FusionX.
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.
This setup allows for Linux or emulated machines, whilst running as an application on the FusionX, to output their sound to the internal speaker.
MZ-700 Video Interface Schematic
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.
![MZ700 VideoInterface Schematic6](../images/VideoInterface_MZ700_V1_0_Schematics-1.png) MZ-700 Video Interface PCB
The MZ-700 daughter board PCB is small and compact due to the space restrictions. It has to fit onto the existing modulator connector and within the available free space.
-------------------------------------------------------------------------------------------------------- ###### MZ-2000 Daughter Board
The purpose of the MZ-2000 daughter board is to interface the video/audio/reset circuits of the FusionX board with those of the MZ-2000. The MZ-2000 has an internal monochrome CRT, external RGB video and internal Audio with an amplifier on the monochrome CRT control board.
The daughter board is designed to be inserted simultaneously into the mainboard monitor and IPL connectors. It presents all the required connectors to connect the IPL/RESET switches, internal monitor and external monitor on the same board.
The IPL and RESET inputs are intercepted on the daughter board and sent to the FusionX as the MZ-2000 operates in different modes dependent on which RESET key is pressed during a Z80 Reset.
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.
The FusionX RGB output is routed to the MZ-2000 external RGB video socket allowing for upto full HD external colour video display.
The sound circuitry of the MZ-2000 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.
MZ-2000 Video Interface Schematic
The MZ-2000 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.
![MZ2000 VideoInterface Schematic6](../images/VideoInterface_MZ2000_V1_0_Schematics-1.png) MZ-2000 Video Interface PCB
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.
-------------------------------------------------------------------------------------------------------- ###### MZ-80A Daughter 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.
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 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.
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 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.
MZ-80A Video Interface Schematic
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.
![MZ80A VideoInterface Schematic6](../images/VideoInterface_MZ80A_V1_0_Schematics-1.png) 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 existing internal cabling.
-------------------------------------------------------------------------------------------------------- ## Reference Sites
The table below contains all the sites referenced in the design and programming of the tranZPUterFusionX
Site Language Description
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.
-------------------------------------------------------------------------------------------------------- ## Manuals and Datasheets
The table below contains all the datasheets and manuals referenced in the design and programming of the tranZPUterFusionX
Datasheet Language Description
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.
-------------------------------------------------------------------------------------------------------- ## Project Preview
Development progress on the tranZPUterFusionX was shared on X (formerly Twitter) as each milestone was reached. The posts below document key stages from the first hardware bring-up through to running RFS, MZ-700 and 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
Demonstration Videos
MZ-80A Demo (includes virtual RFS Board)

pic.twitter.com/3gbEHVzS6X

— engineers@work (@engineerswork1) February 13, 2023
MZ-2000 Demo

pic.twitter.com/ZP4T3oisrg

— engineers@work (@engineerswork1) November 27, 2022
MZ-700 Demo

pic.twitter.com/6lJoGkNuiP

— engineers@work (@engineerswork1) October 30, 2022
-------------------------------------------------------------------------------------------------------- ## Credits
The Z80 Emulation used in the FusionX is (c) 1999-2022 Manuel Sainz de Baranda y Goñi, which is licensed under the LGPL v3 license, source can be found in Gitea.
The SSD202/SOM2D0X build system is based on Linux with extensions by SigmaStar and Industio, licensing can be found in their updated source files.
-------------------------------------------------------------------------------------------------------- ## Licenses
This design, hardware and software (attributable components excluding separately licensed software) is licensed under the GNU Public Licence v3 and free to use, adapt and modify by individuals, groups and educational institutes.
No commercial use to be made of this design or any hardware/firmware component without express permission from the author.
-------------------------------------------------------------------------------------------------------- ## The Gnu Public License v3
The source and binary files in this project marked as GPL v3 are free software: you can redistribute it and-or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

The source files are distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/.
--------------------------------------------------------------------------------------------------------