eaw/tzpuFusionX
1
0
Fork 0
Code Issues Packages Projects Releases 1 Wiki Activity

Update README from eaw.app website content

Browse Source
This commit is contained in:
eaw
2026-03-14 10:07:20 +00:00
parent dcb308f0df
commit 9baeec811b
1 changed files with 522 additions and 50 deletions
Download Patch File Download Diff File Expand all files Collapse all files

572
README.md vendored
View File

@@ -1,4 +1,10 @@
<img src='http://eaw.app/images/FusionX_Wired.png' height='70%' width='70%' style="margin-left: auto; margin-right: auto; display: block;"/>
# tzpuFusionX
**Website:** [engineers@work](https://eaw.app) | **Repository:** [git.eaw.app/eaw/tzpuFusionX](https://git.eaw.app/eaw/tzpuFusionX)
---
<img src='../images/FusionX_Wired.png' height='70%' width='70%' style="margin-left: auto; margin-right: auto; display: block;"/>
## <font style="color: yellow;" size="6">Overview</font>
@@ -7,7 +13,7 @@ The tran<i>ZPU</i>ter<sup><i>FusionX</i></sup> is a spinoff concept from the tra
rapid application loading from SD card and by using a daughter board, better graphics and sound.
<div style="padding-top: 0.8em;"></div>
The <i>FusionX</i> 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 <i>FusionX</i>.
The <i>FusionX</i> 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 <i>FusionX</i>.
<div style="padding-top: 0.8em;"></div>
It shares similarities with the tran<i>ZPU</i>ter<sup><i>Fusion</i></sup> but instead of realising it in hardware via an FPGA it realises
@@ -18,7 +24,7 @@ Using the same base design as the tran<i>ZPU</i>ter<sup><i>Fusion</i></sup> it i
<div style="padding-top: 0.8em;"></div>
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.
<div style="padding-top: 0.8em;"></div>
Like the tran<i>ZPU</i>ter<sup><i>Fusion</i></sup>, the tran<i>ZPU</i>ter<sup><i>FusionX</i></sup> 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 tran<i>ZPU</i>ter<sup><i>Fusion</i></sup>, the tran<i>ZPU</i>ter<sup><i
The <i>FusionX</i> 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.
<div style="padding-top: 0.8em;"></div>
To most retro users, in the early stages of <i>FusionX</i> 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:
<ul style="line-height: 0.9em;"><font size="3">
To most retro users, in the early stages of <i>FusionX</i> 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:
<ul style="line-height: 1.6em;"><font size="3">
<li><font style="color: orange;" size="3">Original host specifications</font><br>- 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.</li>
<li><font style="color: orange;" size="3">Accelerator</font><br>- 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.</li>
<li><font style="color: orange;" size="3">Emulation</font><br>- emulation of all the Sharp MZ series machines, experiencing it through the host system keyboard, monitor and I/O.</li>
@@ -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.
</div>
![FusionX Schematic2](http://eaw.app/images/tzpuFusionX_v1_0_Schematics-2.png)
![FusionX Schematic2](../images/tzpuFusionX_v1_0_Schematics-2.png)
<font style="color: cyan;" size="4">Schematic 2 - I/O (Audio, UART, USB)</font>
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
The SOM is rich in peripherals and this circuit interfaces some of them for use in the FusionX, these include:
<ul style="line-height: 0.9em;"><font size="3">
<ul style="line-height: 1.6em;"><font size="3">
<li><font style="color: orange;" size="3">Stereo Audio Microphone input</font><br>- a digital microphone input is also available but the pins are used in the CPLD interface.</li>
<li><font style="color: orange;" size="3">Stereo Audio DAC output</font><br>- dual digital to analogue converters for sound output which can be clocked at 48KHz.</li>
<li><font style="color: orange;" size="3">WiFi Antenna</font><br>- 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.</li>
<li><font style="color: orange;" size="3">USB</font><br>- a Linux connected USB port allowing for device expansion, such as additional storage, mice etc.</li>
<li><font style="color: orange;" size="3">Fast UART</font><br>- high speed full duplex with hardware handshake UART.</li>
<li><font style="color: orange;" size="3">UART</font><br>- standard 2 pin UART operating upto 500KHz.</li>
<li><font style="color: orange;" size="3">SD Card</font><br>- 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.</li>
<li><font style="color: orange;" size="3">SD Card</font><br>- 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.</li>
</font></ul>
</div>
![FusionX Schematic2](http://eaw.app/images/tzpuFusionX_v1_0_Schematics-3.png)
![FusionX Schematic2](../images/tzpuFusionX_v1_0_Schematics-3.png)
<font style="color: cyan;" size="4">Schematic 3 - Video (VideoDAC, Contrast DAC)</font>
@@ -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.
</div>
![FusionX Schematic4](http://eaw.app/images/tzpuFusionX_v1_0_Schematics-4.png)
![FusionX Schematic4](../images/tzpuFusionX_v1_0_Schematics-4.png)
<font style="color: cyan;" size="4">Schematic 4 - Power Supply (3.3V, USB)</font>
@@ -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.
</div>
![FusionX Schematic5](http://eaw.app/images/tzpuFusionX_v1_0_Schematics-5.png)
![FusionX Schematic5](../images/tzpuFusionX_v1_0_Schematics-5.png)
<font style="color: cyan;" size="4">Schematic 5 - CPLD Interface</font>
@@ -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.
<div style="padding-top: 0.8em;"></div>
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.
</div>
![FusionX Schematic6](http://eaw.app/images/tzpuFusionX_v1_0_Schematics-6.png)
![FusionX Schematic6](../images/tzpuFusionX_v1_0_Schematics-6.png)
#### <font style="color: yellow;" size="5">PCB
#### <font style="color: yellow;" size="5">PCB</font>
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
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 tran<i>ZPU</i>ter<sup><i>Fusion</i></sup> for interchangeability.
<div style="padding-top: 0.8em;"></div>
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.
<div style="padding-top: 0.8em;"></div>
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.
<div style="padding-top: 0.8em;"></div>
</div>
<font style="color: cyan;" size="4">PCB Top Overview</font>
![FusionX PCB Top](http://eaw.app/images/tzpuFusionX_v1_0_3D_Top.png)
![FusionX PCB Top](../images/tzpuFusionX_v1_0_3D_Top.png)
<font style="color: cyan;" size="4">PCB Bottom Overview</font>
![FusionX PCB Bottom](http://eaw.app/images/tzpuFusionX_v1_0_3D_Bottom.png)
![FusionX PCB Bottom](../images/tzpuFusionX_v1_0_3D_Bottom.png)
<font style="color: cyan;" size="4">PCB 4 Layer Routing Overview</font>
![FusionX Routing](http://eaw.app/images/tzpuFusionX_v1_0_layout.png)
![FusionX Routing](../images/tzpuFusionX_v1_0_layout.png)
<font style="color: cyan;" size="4">PCB Assembled</font>
![FusionX Assembled](http://eaw.app/images/FusionX_Top.png)
![FusionX Assembled](../images/FusionX_Top.png)
![FusionX Assembled](http://eaw.app/images/FusionX_Bottom.png)
![FusionX Assembled](../images/FusionX_Bottom.png)
<font style="color: cyan;" size="4">PCB Component Placement and Bill of Materials</font>
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
Click <a href="http://eaw.app/_pages/FusionX_v1_0_BOM.html">here</a> to view an interactive PCB component placement diagram and Bill of Materials.
Click <a href="../_pages/FusionX_v1_0_BOM.html">here</a> to view an interactive PCB component placement diagram and Bill of Materials.
</div>
--------------------------------------------------------------------------------------------------------
<a name="cpld" id="cpld"></a>
###### <font style="color: yellow;" size="5">CPLD</font>
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
The tran<i>ZPU</i>ter<sup><i>FusionX</i></sup> uses an Altera MAX7000AE CPLD — specifically the <b>EPM7512AETC144-10</b> — 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.
<div style="padding-top: 0.8em;"></div>
The CPLD design is written in VHDL and built with <b>Altera Quartus II 13.0.1 SP1 (Web Edition)</b>. Because each host machine has slightly different bus timing requirements and memory map constraints, a separate VHDL implementation is maintained for each supported host:
</div>
<div style="padding-top: 0.4em;"></div>
| 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/` |
<div style="padding-top: 1.2em;"></div>
<a name="cpld-purpose" id="cpld-purpose"></a>
<font style="color: cyan;" size="4">Purpose and Role</font>
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
The CPLD performs several functions that would be impractical or impossible to implement directly in software on the SOM:
<ul style="line-height: 1.6em;"><font size="3">
<li><font style="color: orange;" size="3">Voltage level translation</font><br>— 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.</li>
<li><font style="color: orange;" size="3">Cycle-accurate Z80 bus timing</font><br>— 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.</li>
<li><font style="color: orange;" size="3">SOM interface bridging</font><br>— 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.</li>
<li><font style="color: orange;" size="3">Video and audio switching</font><br>— 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.</li>
<li><font style="color: orange;" size="3">Video sync and clock generation</font><br>— Generates composite sync (<code>VGA_CSYNCn</code>) 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 (<code>VGA_COLR</code>) for composite colour output.</li>
<li><font style="color: orange;" size="3">Reset management</font><br>— 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 <code>PM_RESET</code> line to force a full SOM power-cycle reboot.</li>
<li><font style="color: orange;" size="3">USB power control</font><br>— Controls the USB VBUS power enable signal under SOM command.</li>
</font></ul>
</div>
<div style="padding-top: 1.2em;"></div>
<a name="cpld-fsm" id="cpld-fsm"></a>
<font style="color: cyan;" size="4">Z80 Bus FSM</font>
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
The heart of the CPLD design is a finite state machine (<code>SOMFSMState</code>) 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:
</div>
<div style="padding-top: 0.4em;"></div>
| 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. |
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
<div style="padding-top: 0.8em;"></div>
Each state has numbered sub-states (e.g. <code>FetchCycle_11</code>, <code>FetchCycle_20</code>) 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.
<div style="padding-top: 0.8em;"></div>
A secondary <code>CTRLFSMState</code> FSM handles SPI command processing (<code>CTRLCMD_Idle</code> → <code>CTRLCMD_ReadIOWrite</code>) independently of the main bus cycle FSM, so that SPI transactions from the SOM do not block Z80 bus cycle servicing.
</div>
<div style="padding-top: 1.2em;"></div>
<a name="cpld-som-interface" id="cpld-som-interface"></a>
<font style="color: cyan;" size="4">SOM Interface</font>
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
The CPLD presents two distinct interfaces to the SOM:
<ul style="line-height: 1.6em;"><font size="3">
<li><font style="color: orange;" size="3">SPI slave (write path)</font><br>— A 4-wire SPI slave (<code>VSOM_SPI_CLK</code>, <code>VSOM_SPI_MOSI</code>, <code>VSOM_SPI_MISO</code>, <code>VSOM_SPI_CSn</code>) 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 (<code>SPI_CLK_POLARITY</code>) to accommodate different SOM SPI configurations.</li>
<li><font style="color: orange;" size="3">8-bit parallel bus (read path)</font><br>— An 8-bit output bus (<code>VSOM_DATA_OUT[7:0]</code>) with a <code>VSOM_HBYTE</code> 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: <code>VSOM_READY</code> (FSM idle), <code>VSOM_LTSTATE</code> (last T-state of current cycle), <code>VSOM_BUSRQ</code>, <code>VSOM_BUSACK</code>, <code>VSOM_INT</code>, <code>VSOM_NMI</code>, <code>VSOM_WAIT</code>, and <code>VSOM_RESET</code>.</li>
</font></ul>
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.
</div>
<div style="padding-top: 1.2em;"></div>
<a name="cpld-build" id="cpld-build"></a>
<font style="color: cyan;" size="4">Building the CPLD Image</font>
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
The CPLD bitstream is produced using <b>Altera Quartus II 13.0.1 SP1 Web Edition</b>, 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.
<div style="padding-top: 0.8em;"></div>
<font style="color: cyan;" size="3">Opening the Project</font><br>
Each host machine variant has its own Quartus project in the corresponding subdirectory. To build the MZ-80A variant, for example:
<pre style="font-size: 0.70em; line-height: 1.3em; background: #1a1a1a; padding: 1em; border-radius: 4px; overflow-x: auto;"># 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
</pre>
The project references three VHDL source files (paths relative to the project <code>build/</code> directory):
<ul style="line-height: 1.6em;"><font size="3">
<li><code>../tzpuFusionX_Toplevel.vhd</code> — top-level entity instantiation and I/O pin definitions</li>
<li><code>../tzpuFusionX_pkg.vhd</code> — shared package (types, constants)</li>
<li><code>../tzpuFusionX.vhd</code> — main RTL architecture (FSMs, SPI, bus interface, video/audio control)</li>
</font></ul>
<font style="color: cyan;" size="3">Compilation</font><br>
In the Quartus GUI select <b>Processing → Start Compilation</b> (or press Ctrl+L). The tool runs Analysis &amp; Synthesis, Fitter, Assembler and Timing Analysis in sequence. A successful build produces:
<pre style="font-size: 0.70em; line-height: 1.3em; background: #1a1a1a; padding: 1em; border-radius: 4px; overflow-x: auto;">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
</pre>
The <code>.pof</code> file is the binary image used to program the physical CPLD device.
<div style="padding-top: 0.8em;"></div>
<font style="color: cyan;" size="3">Programming the CPLD</font><br>
Programming is performed via JTAG using an Altera USB-Blaster or compatible JTAG adapter connected to the 10-pin JTAG header on the <i>FusionX</i> board:
<ol style="line-height: 1.6em;"><font size="3">
<li>Connect the USB-Blaster to the <i>FusionX</i> JTAG header and the host PC.</li>
<li>Power the <i>FusionX</i> board (the CPLD must be powered during programming).</li>
<li>In Quartus II, open <b>Tools → Programmer</b>.</li>
<li>Load the chain description file: <code>build/output_files/tzpuFusionX_MZ80A.cdf</code>.</li>
<li>Verify the USB-Blaster is detected in the hardware list, then click <b>Start</b>.</li>
<li>Programming completes in a few seconds; the CPLD becomes active immediately on completion.</li>
</font></ol>
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.
</div>
--------------------------------------------------------------------------------------------------------
## <font style="color: yellow;" size="6">Software</font>
<font size="2">Under construction.</font>
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
The <i>FusionX</i> 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 <i>FusionX</i> startup script then configures the system and brings the Z80 emulator online.
<div style="padding-top: 0.8em;"></div>
The software components are:
<ul style="line-height: 1.6em;"><font size="3">
<li><font style="color: orange;" size="3">Linux OS</font><br>— Kernel 4.9-rt (PREEMPT_RT) with Buildroot root filesystem running on the SigmaStar SSD202 dual-core Cortex-A7.</li>
<li><font style="color: orange;" size="3">z80drv.ko</font><br>— Linux kernel module implementing the Z80 CPU emulator and host hardware interface. Runs the Z80 emulation loop on a dedicated CPU core.</li>
<li><font style="color: orange;" size="3">ttymzdrv.ko</font><br>— Linux TTY kernel module that presents the Sharp MZ keyboard and display as a standard Linux terminal device (<code>/dev/ttymz0</code>).</li>
<li><font style="color: orange;" size="3">z80ctrl</font><br>— 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.</li>
<li><font style="color: orange;" size="3">k64fcpu</font><br>— User-space daemon emulating a K64F virtual CPU. Used in TZFS mode to manage ROM loading and inter-processor communication with the Z80 emulator.</li>
<li><font style="color: orange;" size="3">sharpbiter</font><br>— Sharp MZ arbiter daemon, coordinating access to the shared Sharp MZ hardware resources between the Z80 emulator and the Linux TTY driver.</li>
</font></ul>
Startup is handled by <code>start_FusionX.sh</code>, which loads <code>ttymzdrv.ko</code>, starts a getty login session on <code>/dev/ttymz0</code>, pins all Linux processes and IRQs to CPU0, loads <code>z80drv.ko</code> onto the isolated CPU1, then launches the <code>k64fcpu</code> and <code>sharpbiter</code> daemons. Two pre-built startup modes are provided:
<ul style="line-height: 1.6em;"><font size="3">
<li><font style="color: orange;" size="3">RFS mode</font><br>(<code>startZ80_RFS.sh</code>) — loads the ROM Filing System virtual hardware device and starts the MZ-80A emulator with 40- or 80-column ROM images.</li>
<li><font style="color: orange;" size="3">TZFS mode</font><br>(<code>startZ80_TZFS.sh</code>) — loads the tranZPUter SW virtual hardware device and starts the <code>k64fcpu</code> K64F daemon which manages Monitor and TZFS ROM image loading.</li>
</font></ul>
</div>
<a name="architecture" id="architecture"></a>
###### <font style="color: yellow;" size="5">Architecture</font>
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
The <i>FusionX</i> 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.
<div style="padding-top: 0.8em;"></div>
<pre style="font-size: 0.70em; line-height: 1.3em; background: #1a1a1a; padding: 1em; border-radius: 4px; overflow-x: auto;">
Sharp MZ Host
+------------------------------------------+
| Z80 DIP-40 Socket |
+--------------+---------------------------+
| Z80 bus (address, data, control)
+--------------v---------------------------+
| CPLD (Altera MAX 7000A) |
| . 5V &lt;-&gt; 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 --&gt; /dev/ttymz0 ||
| | z80ctrl (control utility) ||
| | k64fcpu (K64F daemon) ||
| | sharpbiter (MZ arbiter) ||
| +--------------------------------------+|
+------------------------------------------+
</pre>
</div>
<div style="padding-top: 1.2em;"></div>
<a name="dual-core-design" id="dual-core-design"></a>
<font style="color: cyan;" size="4">Dual-Core Design</font>
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
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.
<div style="padding-top: 0.8em;"></div>
<b>CPU0 — Linux and User-Space Services</b><br>
Runs the complete Linux 4.9-rt operating system, all user-space daemons and handles all hardware interrupts. Key responsibilities on CPU0 include:
<ul style="line-height: 1.6em;"><font size="3">
<li><font style="color: orange;" size="3">ttymzdrv.ko</font><br>— Linux TTY kernel module that maps the Sharp MZ keyboard and display to <code>/dev/ttymz0</code>. 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.</li>
<li><font style="color: orange;" size="3">z80ctrl utility</font><br>— 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 <code>z80drv.ko</code> via a kernel character device.</li>
<li><font style="color: orange;" size="3">k64fcpu daemon</font><br>— 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 <code>z80drv.ko</code>.</li>
<li><font style="color: orange;" size="3">sharpbiter daemon</font><br>— 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.</li>
<li><font style="color: orange;" size="3">WiFi and web server</font><br>— 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.</li>
</font></ul>
<b>CPU1 — Z80 Emulator (dedicated)</b><br>
Exclusively runs the <code>kthread_z80</code> kernel thread spawned by <code>z80drv.ko</code>. No other process or interrupt is ever scheduled on CPU1 after initialisation. The emulation loop on CPU1:
<ul style="line-height: 1.6em;"><font size="3">
<li>Calls the Zeta Z80 CPU core for each instruction execution step</li>
<li>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</li>
<li>Drives the GPIO and SPI hardware via <code>z80io.c</code> to assert or sample the Z80 bus signals through the CPLD</li>
<li>Runs at 1.2GHz with the PREEMPT_RT kernel ensuring minimal interrupt jitter even from CPU0 activity</li>
</font></ul>
</div>
<div style="padding-top: 1.2em;"></div>
<a name="cpld-bus-interface" id="cpld-bus-interface"></a>
<font style="color: cyan;" size="4">CPLD Bus Interface</font>
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
The hardware path from the SOM to the Z80 host socket passes through an Altera MAX 7000A CPLD. This device serves two essential roles:
<ul style="line-height: 1.6em;"><font size="3">
<li><font style="color: orange;" size="3">Voltage level translation</font><br>— 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.</li>
<li><font style="color: orange;" size="3">Cycle-accurate Z80 bus timing</font><br>— 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.</li>
</font></ul>
The SOM communicates with the CPLD through two parallel channels:
<ul style="line-height: 1.6em;"><font size="3">
<li><font style="color: orange;" size="3">SPI channel (50MHz)</font><br>— 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.</li>
<li><font style="color: orange;" size="3">8-bit GPIO bus</font><br>— used by <code>z80io.c</code> 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.</li>
</font></ul>
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 <code>PHYSICAL</code>-type block is encountered (e.g. for host video RAM or hardware registers that must be accessed on the real hardware).
</div>
<div style="padding-top: 1.2em;"></div>
<a name="memory-architecture" id="memory-architecture"></a>
<font style="color: cyan;" size="4">Memory Architecture</font>
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
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 <code>kthread_z80</code> running on CPU1, with no virtual memory translation overhead in the inner emulation loop.
<div style="padding-top: 0.8em;"></div>
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:
</div>
<div style="padding-top: 0.4em;"></div>
| 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. |
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
<div style="padding-top: 0.8em;"></div>
ROM images are loaded into kernel memory at startup by <code>z80ctrl --loadrom</code> (or automatically by the active virtual hardware module or the <code>k64fcpu</code> 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.
<div style="padding-top: 0.8em;"></div>
Machine timing constants for each supported host (MZ-80A, MZ-700, MZ-2000, PCW-8256) are defined in <code>z80driver.h</code> 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.
</div>
<div style="padding-top: 1.2em;"></div>
<a name="virtual-hardware-modules" id="virtual-hardware-modules"></a>
<font style="color: cyan;" size="4">Virtual Hardware Modules</font>
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
Virtual hardware modules are C source files (<code>z80vhw_*.c</code>) that define the behaviour of a specific host machine or peripheral set. Rather than being compiled as separately-linked objects they are <code>#include</code>d directly into <code>z80driver.c</code>, so their handler functions are inlined into the emulation dispatch path with no function-call overhead.
<div style="padding-top: 0.8em;"></div>
Up to five virtual hardware devices can be active simultaneously (<code>MAX_VIRTUAL_DEVICES 5</code>). Devices are registered at runtime before the emulator starts using <code>z80ctrl --adddev --device &lt;name&gt;</code>. 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.
<div style="padding-top: 0.8em;"></div>
The available modules and the host machines they support are:
</div>
<div style="padding-top: 0.4em;"></div>
| 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 <code>k64fcpu</code> daemon to provide K64F virtual CPU behaviour, TZFS ROM page management and CP/M support. |
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
<div style="padding-top: 0.8em;"></div>
The TZPU module (<code>z80vhw_tzpu.c</code>) is architecturally distinct from the others. Because the K64F co-processor behaviour is complex and stateful, it is split across two components: the <code>z80vhw_tzpu.c</code> kernel-side stub handles fast bus-cycle dispatch while the <code>k64fcpu</code> 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.
</div>
<a name="build" id="build"></a>
###### <font style="color: yellow;" size="5">Build</font>
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
The complete <i>FusionX</i> OS and application set is built using the <code>Build_FusionX.sh</code> 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.
<div style="padding-top: 0.8em;"></div>
<font style="color: cyan;" size="4">Prerequisites</font>
<ul style="line-height: 1.6em;"><font size="3">
<li>ARM cross-compiler: <code>arm-linux-gnueabihf-gcc</code> (e.g. from <code>gcc-arm-linux-gnueabihf</code> package)</li>
<li>SigmaStar SDK source tree (kernel, U-boot, Buildroot) in the parent directory structure expected by <code>Build_FusionX.sh</code></li>
<li>FusionX application source in the <code>../FusionX</code> directory relative to the linux build directory</li>
<li>Standard build tools: <code>make</code>, <code>cmake</code>, <code>bc</code>, <code>libssl-dev</code></li>
</font></ul>
<font style="color: cyan;" size="4">Building the Full OS Image</font>
The build is launched from the <code>software/linux/</code> directory:
<pre style="font-size: 0.70em; line-height: 1.3em; background: #1a1a1a; padding: 1em; border-radius: 4px; overflow-x: auto;"># Build full image for FusionX (project 2D06, SPI NAND, SSD202, 256MB flash)
./Build_FusionX.sh -f nand -p ssd202 -o 2D06 -m 256
</pre>
This builds in sequence: U-boot bootloader, Linux kernel (using the FusionX custom defconfig <code>infinity2m_spinand_fusionx_defconfig</code>), Buildroot root filesystem and the FusionX application set. Output images are written to <code>project/image/output/images/</code>.
For the standard SigmaStar reference configuration use project <code>2D07</code> instead.
<div style="padding-top: 0.8em;"></div>
<font style="color: cyan;" size="4">Building Kernel Modules Only</font>
The kernel modules can be rebuilt independently against an already-built kernel tree, which is useful during development:
<pre style="font-size: 0.70em; line-height: 1.3em; background: #1a1a1a; padding: 1em; border-radius: 4px; overflow-x: auto;"># Build z80drv kernel module
cd software/FusionX/src/z80drv/src.mz80a
make
# Build ttymzdrv kernel module
cd software/FusionX/src/ttymz
make
</pre>
The resulting <code>z80drv.ko</code> and <code>ttymzdrv.ko</code> files can be copied directly to the <code>/apps/FusionX/modules/</code> directory on the running SOM (via SSH or SD card) and loaded with <code>insmod</code>.
<div style="padding-top: 0.8em;"></div>
<font style="color: cyan;" size="4">Flashing and Updates</font>
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.
</div>
###### <font style="color: yellow;" size="5">Linux</font>
<font size="2">Under construction.</font>
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
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.
<div style="padding-top: 0.8em;"></div>
The complete OS image — U-boot bootloader, Linux kernel, Buildroot root filesystem and FusionX application set — is assembled using the <code>Build_FusionX.sh</code> script, a customised version of the SigmaStar SDK build system. Two project targets are defined:
<ul style="line-height: 1.6em;"><font size="3">
<li><font style="color: orange;" size="3">2D06</font><br>— FusionX custom configuration using the <code>infinity2m_spinand_fusionx_defconfig</code> kernel defconfig.</li>
<li><font style="color: orange;" size="3">2D07</font><br>— Standard SigmaStar reference configuration using <code>infinity2m_spinand_ssc011a_s01a_minigui_defconfig</code>.</li>
</font></ul>
The build script is invoked as: <code>Build_FusionX.sh -f nand -p ssd202 -o 2D06 -m 256</code> and produces a full flash image ready for programming to the SOM NAND.
<div style="padding-top: 0.8em;"></div>
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 <code>kthread_z80</code> 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.
<div style="padding-top: 0.8em;"></div>
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.
</div>
###### <font style="color: yellow;" size="5">Z80 Emulator</font>
<font size="2">Under construction.</font>
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
The Z80 emulator is implemented as a Linux kernel module, <code>z80drv.ko</code> (v1.4, April 2023). It uses the <a href="https://github.com/redcode/Z80">Zeta Z80 CPU emulator library</a> 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.
<div style="padding-top: 0.8em;"></div>
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 <code>z80io.c</code>, 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.
<div style="padding-top: 0.8em;"></div>
The emulator supports the following host machines, each with its own virtual hardware module:
<table style="font-size: 0.85em; width: 100%; border-collapse: collapse; margin-top: 0.5em;">
<thead>
<tr style="background: #2a2a2a;">
<th style="padding: 0.4em 0.8em; text-align: left; border: 1px solid #444;">Virtual Hardware Module</th>
<th style="padding: 0.4em 0.8em; text-align: left; border: 1px solid #444;">Host Machine</th>
<th style="padding: 0.4em 0.8em; text-align: left; border: 1px solid #444;">Description</th>
</tr>
</thead>
<tbody>
<tr><td style="padding: 0.4em 0.8em; border: 1px solid #444;"><code>z80vhw_mz80a.c</code></td><td style="padding: 0.4em 0.8em; border: 1px solid #444;">Sharp MZ-80A</td><td style="padding: 0.4em 0.8em; border: 1px solid #444;">Original MZ-80A behaviour, no additions</td></tr>
<tr><td style="padding: 0.4em 0.8em; border: 1px solid #444;"><code>z80vhw_mz700.c</code></td><td style="padding: 0.4em 0.8em; border: 1px solid #444;">Sharp MZ-700</td><td style="padding: 0.4em 0.8em; border: 1px solid #444;">Original MZ-700 behaviour, no additions</td></tr>
<tr><td style="padding: 0.4em 0.8em; border: 1px solid #444;"><code>z80vhw_mz2000.c</code></td><td style="padding: 0.4em 0.8em; border: 1px solid #444;">Sharp MZ-2000</td><td style="padding: 0.4em 0.8em; border: 1px solid #444;">MZ-2000 emulation</td></tr>
<tr><td style="padding: 0.4em 0.8em; border: 1px solid #444;"><code>z80vhw_pcw.c</code></td><td style="padding: 0.4em 0.8em; border: 1px solid #444;">Amstrad PCW-8256</td><td style="padding: 0.4em 0.8em; border: 1px solid #444;">PCW-8256 emulation</td></tr>
<tr><td style="padding: 0.4em 0.8em; border: 1px solid #444;"><code>z80vhw_rfs.c</code></td><td style="padding: 0.4em 0.8em; border: 1px solid #444;">MZ-80A + RFS</td><td style="padding: 0.4em 0.8em; border: 1px solid #444;">ROM Filing System virtual hardware for MZ-80A</td></tr>
<tr><td style="padding: 0.4em 0.8em; border: 1px solid #444;"><code>z80vhw_tzpu.c</code></td><td style="padding: 0.4em 0.8em; border: 1px solid #444;">MZ-80A + tranZPUter SW</td><td style="padding: 0.4em 0.8em; border: 1px solid #444;">tranZPUter SW virtual hardware; combines kernel driver with userspace <code>k64fcpu</code> daemon</td></tr>
</tbody>
</table>
<div style="padding-top: 0.8em;"></div>
The virtual hardware modules are compiled inline into <code>z80drv.ko</code> 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 (<code>MAX_VIRTUAL_DEVICES 5</code>). Devices are added at runtime using <code>z80ctrl --adddev --device &lt;name&gt;</code> before starting the emulator.
<div style="padding-top: 0.8em;"></div>
The <code>z80ctrl</code> utility provides full runtime control of the emulator from the Linux command line:
<ul style="line-height: 1.6em;"><font size="3">
<li><code>--adddev --device &lt;name&gt;</code> — add a virtual hardware device (rfs, tzpu, mz700, mz80a, mz2000, pcw)</li>
<li><code>--start</code> / <code>--stop</code> — start or stop the Z80 emulation loop</li>
<li><code>--loadrom --file &lt;path&gt; --addr &lt;hex&gt; --type &lt;n&gt;</code> — load a ROM binary into emulated memory</li>
<li><code>--mem --addr &lt;hex&gt; --len &lt;n&gt;</code> — inspect emulated memory contents</li>
<li><code>--cmd &lt;hex&gt;</code> — send a command byte directly to the CPLD/Z80 gateway</li>
</font></ul>
<div style="padding-top: 0.8em;"></div>
The <code>ttymzdrv.ko</code> module (<code>ttymz.c</code>, v1.2, July 2023) provides a standard Linux TTY interface on <code>/dev/ttymz0</code> 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.
</div>
--------------------------------------------------------------------------------------------------------
## <font style="color: yellow;" size="6">Daughter Boards</font>
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
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.
<div style="padding-top: 0.8em;"></div>
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
<div style="padding-top: 0.8em;"></div>
During the design of the tran<i>ZPU</i>ter<sup><i>FusionX</i></sup> one of the main requirements was to make the board small, the Z80 orientation changeable and also compatible with the tran<i>ZPU</i>ter<sup><i>Fusion</i></sup> 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 tran<i>ZPU</i>ter<sup>FusionX</sup> 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 tran<i>ZPU</i>ter<sup><i>FusionX</i></sup> to a daughter board which would be
and each was quite different, it became apparent that the tran<i>ZPU</i>ter<sup><i>FusionX</i></sup> 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 tran<i>ZPU</i>ter<sup><i>FusionX</i></sup> to a daughter board which would be
specifically designed for the intended host.
<div style="padding-top: 0.8em;"></div>
@@ -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 <i>FusionX</i> under control of the <i>FusionX</i>.
<div style="padding-top: 0.8em;"></div>
The original sound circuity of the MZ-700 drives a speaker directly and in order to inject <i>FusionX</i> audio into the MZ-700 speaker, the mainboard speaker output is routed to the daughter board, level converted and switched under control of the <i>FusionX</I>. The <i>FusionX</i> 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 <i>FusionX</i> audio into the MZ-700 speaker, the mainboard speaker output is routed to the daughter board, level converted and switched under control of the <i>FusionX</I>. The <i>FusionX</i> 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.
<div style="padding-top: 0.8em;"></div>
@@ -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 <i>FusionX</i> control and a Class D power amplifier.
</div>
![MZ700 VideoInterface Schematic6](http://eaw.app/images/VideoInterface_MZ700_V1_0_Schematics-1.png)
![MZ700 VideoInterface Schematic6](../images/VideoInterface_MZ700_V1_0_Schematics-1.png)
<font style="color: cyan;" size="4">MZ-700 Video Interface PCB</font>
@@ -251,16 +677,16 @@ The MZ-700 daughter board PCB is small and compact due to the space restrictions
<div style='content: ""; clear: both; display: table;'>
<div style='width: 35%; padding: 5px; padding-left: 1em; float: left'>
<img src='http://eaw.app/images/VideoInterface_MZ700_v1_0_3D_Top.png' height='100%' width='100%' style="margin-left: auto; margin-right: auto; display: block;"/>
<img src='../images/VideoInterface_MZ700_v1_0_3D_Top.png' height='100%' width='100%' style="margin-left: auto; margin-right: auto; display: block;"/>
</div>
<div style='width: 39%; padding: 5px; padding-left: 1em; float: left'>
<img src='http://eaw.app/images/VideoInterface_MZ700_v1_0_3D_Bottom.png' height='100%' width='100%' style="margin-left: auto; margin-right: auto; display: block;"/>
<img src='../images/VideoInterface_MZ700_v1_0_3D_Bottom.png' height='100%' width='100%' style="margin-left: auto; margin-right: auto; display: block;"/>
</div>
</div>
<div style='content: ""; clear: both; display: table;'>
<div style='width: 80%; padding: 5px; padding-left: 1em; float: left'>
<img src='http://eaw.app/images/FusionX_MZ700.png' height='100%' width='100%' style="margin-left: auto; margin-right: auto; display: block;"/>
<img src='../images/FusionX_MZ700.png' height='100%' width='100%' style="margin-left: auto; margin-right: auto; display: block;"/>
</div>
</div>
@@ -284,7 +710,7 @@ The video signals from the mainboard are switched with the <i>FusionX</i> video
The <i>FusionX</i> RGB output is routed to the MZ-2000 external RGB video socket allowing for upto full HD external colour video display.
<div style="padding-top: 0.8em;"></div>
The sound circuity of the MZ-2000 is sent to an audio amplifier on the CRT monitor. This signal is intercepted and switched with the <i>FusionX</i> 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-2000 is sent to an audio amplifier on the CRT monitor. This signal is intercepted and switched with the <i>FusionX</i> audio which then drives the CRT monitor amplifier. Line level stereo output is achieved via an additional 4pin connector and used as required.
<div style="padding-top: 0.8em;"></div>
</div>
@@ -295,26 +721,26 @@ The sound circuity of the MZ-2000 is sent to an audio amplifier on the CRT monit
The MZ-2000 daughter board consists of two 4way SPDT analogue switches to route video and audio signals under <i>FusionX</i> control. One SPDT switch is used for creating pure black in the modified video signal generated on the <i>FusionX</i> board.
</div>
![MZ2000 VideoInterface Schematic6](http://eaw.app/images/VideoInterface_MZ2000_V1_0_Schematics-1.png)
![MZ2000 VideoInterface Schematic6](../images/VideoInterface_MZ2000_V1_0_Schematics-1.png)
<font style="color: cyan;" size="4">MZ-2000 Video Interface PCB</font>
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
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.
</div>
<div style='content: ""; clear: both; display: table;'>
<div style='width: 50%; padding: 5px; padding-left: 1em; float: left'>
<img src='http://eaw.app/images/VideoInterface_MZ2000_v1_0_3D_Top.png' height='100%' width='100%' style="margin-left: auto; margin-right: auto; display: block;"/>
<img src='../images/VideoInterface_MZ2000_v1_0_3D_Top.png' height='100%' width='100%' style="margin-left: auto; margin-right: auto; display: block;"/>
</div>
<div style='width: 50%; padding: 5px; padding-left: 1em; float: left'>
<img src='http://eaw.app/images/VideoInterface_MZ2000_v1_0_3D_Bottom.png' height='100%' width='100%' style="margin-left: auto; margin-right: auto; display: block;"/>
<img src='../images/VideoInterface_MZ2000_v1_0_3D_Bottom.png' height='100%' width='100%' style="margin-left: auto; margin-right: auto; display: block;"/>
</div>
</div>
<div style='content: ""; clear: both; display: table;'>
<div style='width: 60%; padding: 5px; padding-left: 1em; float: left'>
<img src='http://eaw.app/images/FusionX_MZ2000.png' height='80%' width='100%' style="margin-left: auto; margin-right: auto; display: block;"/>
<img src='../images/FusionX_MZ2000.png' height='80%' width='100%' style="margin-left: auto; margin-right: auto; display: block;"/>
</div>
</div>
@@ -323,7 +749,7 @@ The MZ-2000 daughter board PCB is small and compact due to the space restriction
###### <font style="color: yellow;" size="5">MZ-80A Daughter Board</font>
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
The purpose of the MZ-80A daughter board is to interface the video/audio/reset circuits of the <i>FusionX</I> 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 <i>FusionX</I> 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.
<div style="padding-top: 0.8em;"></div>
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.
<div style="padding-top: 0.8em;"></div>
The RESET input is intercepted on the daughter board and sent to the <i>FusionX</i>. Technically it isnt needed as the <i>FusionX</i> 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 <i>FusionX</i>. Technically it isn't needed as the <i>FusionX</i> 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.
<div style="padding-top: 0.8em;"></div>
The video signals from the mainboard are switched with the <i>FusionX</i> video monochrome signals and sent to the internal CRT monitor. This allows for original video output on the CRT monitor or advanced <i>FusionX</i> 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 <i>FusionX</i> video
The <i>FusionX</i> RGB output is routed to the MZ-80A external RGB video socket (if installed) allowing for upto full HD external colour video display.
<div style="padding-top: 0.8em;"></div>
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 <i>FusionX</i> 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 <i>FusionX</i> audio which then drives the CRT monitor amplifier. Line level stereo output is achieved via an additional 4pin connector and used as required.
<div style="padding-top: 0.8em;"></div>
</div>
@@ -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 <i>FusionX</i> control. One SPDT switch is used for creating pure black in the modified video signal generated on the <i>FusionX</i> board.
</div>
![MZ80A VideoInterface Schematic6](http://eaw.app/images/VideoInterface_MZ80A_V1_0_Schematics-1.png)
![MZ80A VideoInterface Schematic6](../images/VideoInterface_MZ80A_V1_0_Schematics-1.png)
<font style="color: cyan;" size="4">MZ-80A Video Interface PCB</font>
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
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.
</div>
<div style='content: ""; clear: both; display: table;'>
<div style='width: 47%; padding: 5px; padding-left: 1em; float: left'>
<img src='http://eaw.app/images/VideoInterface_MZ80A_V1_0_3D_Top.png' height='100%' width='100%' style="margin-left: auto; margin-right: auto; display: block;"/>
<img src='../images/VideoInterface_MZ80A_V1_0_3D_Top.png' height='100%' width='100%' style="margin-left: auto; margin-right: auto; display: block;"/>
</div>
<div style='width: 50%; padding: 5px; padding-left: 1em; float: left'>
<img src='http://eaw.app/images/VideoInterface_MZ80A_V1_0_3D_Bottom.png' height='100%' width='100%' style="margin-left: auto; margin-right: auto; display: block;"/>
<img src='../images/VideoInterface_MZ80A_V1_0_3D_Bottom.png' height='100%' width='100%' style="margin-left: auto; margin-right: auto; display: block;"/>
</div>
</div>
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
@@ -384,6 +810,17 @@ The table below contains all the sites referenced in the design and programming
<div style="padding-top: 0.8em;"></div>
<div style="padding-left: 10%;">
<font size="4">
<style>
table {
border-collapse: collapse;
}
tr td {
padding-top: 0em;
}
tr:nth-child(4) td {
padding-top: 0;
}
</style>
<table>
<thead>
<tr>
@@ -438,6 +875,17 @@ The table below contains all the datasheets and manuals referenced in the design
<div style="padding-top: 0.8em;"></div>
<div style="padding-left: 10%;">
<font size="4">
<style>
table {
border-collapse: collapse;
}
tr td {
padding-top: 0em;
}
tr:nth-child(4) td {
padding-top: 0;
}
</style>
<table>
<thead>
<tr>
@@ -548,19 +996,43 @@ The table below contains all the datasheets and manuals referenced in the design
--------------------------------------------------------------------------------------------------------
## <font style="color: yellow;" size="5">Demonstration Videos</font>
<a name="project-preview" id="project-preview"></a>
## <font style="color: yellow;" size="6">Project Preview</font>
<a href="https://t.co/ZP4T3oisrg">MZ-2000 Demo</a>
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
Development progress on the tran<i>ZPU</i>ter<sup><i>FusionX</i></sup> 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:
<div style="padding-top: 0.8em;"></div>
<a href="https://t.co/6lJoGkNuiP">MZ-700 Demo</a>
<a href="https://x.com/engineerswork1/status/1579209688495054849" target="_blank">https://x.com/engineerswork1/status/1579209688495054849</a><br>
<a href="https://x.com/engineerswork1/status/1583918702415577089" target="_blank">https://x.com/engineerswork1/status/1583918702415577089</a><br>
<a href="https://x.com/engineerswork1/status/1596925535787286528" target="_blank">https://x.com/engineerswork1/status/1596925535787286528</a><br>
<a href="https://x.com/engineerswork1/status/1616571495957909510" target="_blank">https://x.com/engineerswork1/status/1616571495957909510</a><br>
<a href="https://x.com/engineerswork1/status/1630985022604804109" target="_blank">https://x.com/engineerswork1/status/1630985022604804109</a>
</div>
<div style="padding-top: 1.2em;"></div>
<a name="demonstration-videos" id="demonstration-videos"></a>
<font style="color: yellow;" size="5">Demonstration Videos</font>
<div style="padding-top: 0.8em;"></div>
<font style="color: cyan;" size="4">MZ-80A Demo (includes virtual RFS Board)</font>
<blockquote class="twitter-tweet" data-dnt="true" data-theme="dark"><p lang="en" dir="ltr"> <a href="https://t.co/3gbEHVzS6X">pic.twitter.com/3gbEHVzS6X</a></p>&mdash; engineers@work (@engineerswork1) <a href="https://twitter.com/engineerswork1/status/1625281950897303553?ref_src=twsrc%5Etfw">February 13, 2023</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
<font style="color: cyan;" size="4">MZ-2000 Demo</font>
<blockquote class="twitter-tweet" data-dnt="true" data-theme="dark"><p lang="zxx" dir="ltr"><a href="https://t.co/ZP4T3oisrg">pic.twitter.com/ZP4T3oisrg</a></p>&mdash; engineers@work (@engineerswork1) <a href="https://twitter.com/engineerswork1/status/1596925985592864768?ref_src=twsrc%5Etfw">November 27, 2022</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
<font style="color: cyan;" size="4">MZ-700 Demo</font>
<blockquote class="twitter-tweet" data-dnt="true" data-theme="dark"><p lang="en" dir="ltr"> <a href="https://t.co/6lJoGkNuiP">pic.twitter.com/6lJoGkNuiP</a></p>&mdash; engineers@work (@engineerswork1) <a href="https://twitter.com/engineerswork1/status/1586864092601630721?ref_src=twsrc%5Etfw">October 30, 2022</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
--------------------------------------------------------------------------------------------------------
## <font style="color: yellow;" size="5">Credits</font>
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
The Z80 Emulation used in the <i>FusionX</i> is (c) 1999-2022 Manuel Sainz de Baranda y Goñi, which is licensed under the LGPL v3 license, source can be found in <a href="https://github.com/redcode/Z80">github</a>.
The Z80 Emulation used in the <i>FusionX</i> is (c) 1999-2022 Manuel Sainz de Baranda y Goñi, which is licensed under the LGPL v3 license, source can be found in <a href="https://github.com/redcode/Z80">Gitea</a>.
<div style="padding-top: 0.8em;"></div>
The SSD202/SOM2D0X build system is based on Linux with extensions by SigmaStar and Industio, licensing can be found in their updated source files.
@@ -571,7 +1043,7 @@ The SSD202/SOM2D0X build system is based on Linux with extensions by SigmaStar a
## <font style="color: yellow;" size="5">Licenses</font>
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
This design, hardware and software (attributable components excluding seperately licensed software) is licensed under the GNU Public Licence v3 and free to use, adapt and modify by individuals, groups and educational institutes.
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.
<div style="padding-top: 0.8em;"></div>
No commercial use to be made of this design or any hardware/firmware component without express permission from the author.