eaw/tzpuFusionX

Fork 0

Files

eaw 9baeec811b Update README from eaw.app website content

2026-03-14 10:07:20 +00:00

78 KiB

Vendored

Raw Permalink Blame History

tzpuFusionX

Website: engineers@work | Repository: git.eaw.app/eaw/tzpuFusionX

Overview

The tranZPUter^FusionX 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 tranZPUter^Fusion 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 tranZPUter^Fusion 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 tranZPUter^Fusion, the tranZPUter^FusionX 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:

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.
Graphics
- all original Sharp MZ graphics modes, regardless of host, including additional resolutions upto HD are available through GPU configuration and these can be selected and programmed on the host in languages such as Basic.
Sound
- the host will have access to the stereo DAC converters, which can playback 48KHz CD quality sound or emulate the SN76489 or basic bit/timer sound of the Sharp series. Sound recording is also possible via the Mic input.
Processors
- there are many software CPU implementations which can be ported to run on this platform, for example the ARM platform CPU emulations of the BBC PiCoPro can readily be ported. This in turn allows the potential for other machines, using the SOM advanced graphics and sound as necessary, allow emulations of machines such as the BBC to run on this Sharp host.
Linux
- using the host keyboard, speaker, monitor etc, a full blooded version of Linux, including Wifi, can be utilised at the host console.

Hardware

Version 1.0 is the first official release of the tranZPUter^FusionX 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 tranZPUter^FusionX.

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.

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:

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 sited inside a retro machine.
USB Serial
- when running Linux, the console is presented on a UART serial device. This serial device is converted into USB for ease of use to view and connect with the Linux console.
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 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.

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.

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.

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.

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 tranZPUter^Fusion 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

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.

CPLD

The tranZPUter^FusionX 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:

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 SOM PM_RESET line to force a full SOM power-cycle reboot.
USB power control
— Controls the USB VBUS power enable signal under SOM command.

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:

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 a VSOM_HBYTE select 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, and VSOM_RESET.

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):

../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)

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:

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.

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:

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.

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:

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 the k64fcpu K64F daemon which manages Monitor and TZFS ROM image loading.

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:

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 with z80drv.ko via 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 to z80drv.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.

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:

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.c to 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

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:

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.

The SOM communicates with the CPLD through two parallel channels:

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 by z80io.c for 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.

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

ARM cross-compiler: arm-linux-gnueabihf-gcc (e.g. from gcc-arm-linux-gnueabihf package)
SigmaStar SDK source tree (kernel, U-boot, Buildroot) in the parent directory structure expected by Build_FusionX.sh
FusionX application source in the ../FusionX directory relative to the linux build directory
Standard build tools: make, cmake, bc, libssl-dev

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:

2D06
— FusionX custom configuration using the infinity2m_spinand_fusionx_defconfig kernel defconfig.
2D07
— Standard SigmaStar reference configuration using infinity2m_spinand_ssc011a_s01a_minigui_defconfig.

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.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

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:

--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 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 tranZPUter^FusionX one of the main requirements was to make the board small, the Z80 orientation changeable and also compatible with the tranZPUter^Fusion 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 tranZPUter^FusionX 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 tranZPUter^FusionX 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.

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.

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 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.

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 tranZPUter^FusionX

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 tranZPUter^FusionX

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 tranZPUter^FusionX 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 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/.

78 KiB Vendored Raw Permalink Blame History Unescape Escape