1067 lines
78 KiB
Markdown
Vendored
1067 lines
78 KiB
Markdown
Vendored
# 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>
|
||
|
||
<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> 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.
|
||
<div style="padding-top: 0.8em;"></div>
|
||
|
||
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
|
||
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.
|
||
<div style="padding-top: 0.8em;"></div>
|
||
|
||
Using the same base design as the tran<i>ZPU</i>ter<sup><i>Fusion</i></sup> 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.
|
||
<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 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.
|
||
<div style="padding-top: 0.8em;"></div>
|
||
|
||
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 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>
|
||
<li><font style="color: orange;" size="3">Graphics</font><br>- 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.</li>
|
||
<li><font style="color: orange;" size="3">Sound</font><br>- 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.</li>
|
||
<li><font style="color: orange;" size="3">Processors</font><br>- 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.</li>
|
||
<li><font style="color: orange;" size="3">Linux</font><br>- using the host keyboard, speaker, monitor etc, a full blooded version of Linux, including Wifi, can be utilised at the host console.</li>
|
||
</font></ul>
|
||
|
||
</div>
|
||
|
||
|
||
--------------------------------------------------------------------------------------------------------
|
||
|
||
## <font style="color: yellow;" size="6">Hardware</font>
|
||
|
||
|
||
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
|
||
Version 1.0 is the first official release of the tran<i>ZPU</i>ter<sup><i>FusionX</i></sup> design.
|
||
<div style="padding-top: 0.8em;"></div>
|
||
|
||
The <i>FusionX</i> 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.
|
||
<div style="padding-top: 0.8em;"></div>
|
||
|
||
In addition the <i>FusionX</i> 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 <a href='../Downloads/SSD202D_ProductBrief_v01.pdf'>product brief</a>.
|
||
<div style="padding-top: 0.8em;"></div>
|
||
|
||
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.
|
||
<div style="padding-top: 0.8em;"></div>
|
||
|
||
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.
|
||
<div style="padding-top: 0.8em;"></div>
|
||
|
||
This section outlines the mainboard schematics and circuit board design of the tran<i>ZPU</i>ter<sup><i>FusionX</i></sup>.
|
||
</div>
|
||
|
||
## <font style="color: yellow;" size="5">Schematics</font>
|
||
|
||
<div style="padding-top: 0.8em;"></div>
|
||
|
||
<font style="color: cyan;" size="4">Schematic 1 - Z80 Host socket to CPLD</font>
|
||
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
|
||
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.
|
||
<div style="padding-top: 0.8em;"></div>
|
||
|
||
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>
|
||
|
||
|
||
|
||
<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: 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
|
||
sited inside a retro machine.</li>
|
||
<li><font style="color: orange;" size="3">USB Serial</font><br>- 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.</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 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>
|
||
|
||
|
||
|
||
<font style="color: cyan;" size="4">Schematic 3 - Video (VideoDAC, Contrast DAC)</font>
|
||
|
||
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
|
||
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.
|
||
<div style="padding-top: 0.8em;"></div>
|
||
|
||
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.
|
||
<div style="padding-top: 0.8em;"></div>
|
||
|
||
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>
|
||
|
||
|
||
|
||
<font style="color: cyan;" size="4">Schematic 4 - Power Supply (3.3V, USB)</font>
|
||
|
||
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
|
||
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.
|
||
<div style="padding-top: 0.8em;"></div>
|
||
|
||
Additionally, a software controlled USB power switch is installed to enable (and reset if required) +5V power to the USB expansion port.
|
||
</div>
|
||
|
||
|
||
|
||
<font style="color: cyan;" size="4">Schematic 5 - CPLD Interface</font>
|
||
|
||
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
|
||
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 separate Z80 state information.
|
||
</div>
|
||
|
||
|
||
|
||
#### <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 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 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>
|
||
|
||
|
||
|
||
<font style="color: cyan;" size="4">PCB Bottom Overview</font>
|
||
|
||
|
||
|
||
<font style="color: cyan;" size="4">PCB 4 Layer Routing Overview</font>
|
||
|
||
|
||
|
||
<font style="color: cyan;" size="4">PCB Assembled</font>
|
||
|
||
|
||
|
||
|
||
|
||
|
||
<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="../_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 & 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>
|
||
|
||
<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 <-> 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) ||
|
||
| +--------------------------------------+|
|
||
+------------------------------------------+
|
||
</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 <name></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>
|
||
|
||
<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>
|
||
|
||
<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 <name></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 <name></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 <path> --addr <hex> --type <n></code> — load a ROM binary into emulated memory</li>
|
||
<li><code>--mem --addr <hex> --len <n></code> — inspect emulated memory contents</li>
|
||
<li><code>--cmd <hex></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 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
|
||
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.
|
||
<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><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>
|
||
|
||
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.
|
||
<div style="padding-top: 0.8em;"></div>
|
||
|
||
Currently three daughter boards have been developed, for the MZ-700, MZ-80A and MZ-2000 and more will follow as the design progresses.
|
||
</div>
|
||
|
||
--------------------------------------------------------------------------------------------------------
|
||
|
||
###### <font style="color: yellow;" size="5">MZ-700 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-700 daughter board is to interface the video/audio circuits of the <i>FusionX</I> 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 <i>FusionX</i> under control of the <i>FusionX</i>.
|
||
<div style="padding-top: 0.8em;"></div>
|
||
|
||
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>
|
||
|
||
This setup allows for Linux or emulated machines, whilst running as an application on the <i>FusionX</i>, to output their sound to the internal speaker.
|
||
<div style="padding-top: 0.8em;"></div>
|
||
</div>
|
||
|
||
|
||
<font style="color: cyan;" size="4">MZ-700 Video Interface Schematic</font>
|
||
|
||
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
|
||
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>
|
||
|
||
|
||
|
||
<font style="color: cyan;" size="4">MZ-700 Video Interface PCB</font>
|
||
|
||
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
|
||
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.
|
||
</div>
|
||
|
||
<div style='content: ""; clear: both; display: table;'>
|
||
<div style='width: 35%; padding: 5px; padding-left: 1em; float: left'>
|
||
<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='../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='../images/FusionX_MZ700.png' height='100%' width='100%' style="margin-left: auto; margin-right: auto; display: block;"/>
|
||
</div>
|
||
</div>
|
||
|
||
--------------------------------------------------------------------------------------------------------
|
||
|
||
###### <font style="color: yellow;" size="5">MZ-2000 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-2000 daughter board is to interface the video/audio/reset circuits of the <i>FusionX</I> 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.
|
||
<div style="padding-top: 0.8em;"></div>
|
||
|
||
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.
|
||
<div style="padding-top: 0.8em;"></div>
|
||
|
||
The IPL and RESET inputs are intercepted on the daughter board and sent to the <i>FusionX</i> as the MZ-2000 operates in different modes dependent on which RESET key is pressed during a Z80 Reset.
|
||
<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.
|
||
<div style="padding-top: 0.8em;"></div>
|
||
|
||
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 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>
|
||
|
||
<font style="color: cyan;" size="4">MZ-2000 Video Interface Schematic</font>
|
||
|
||
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
|
||
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>
|
||
|
||
|
||
|
||
<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 existing internal cabling.
|
||
</div>
|
||
|
||
<div style='content: ""; clear: both; display: table;'>
|
||
<div style='width: 50%; padding: 5px; padding-left: 1em; float: left'>
|
||
<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='../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='../images/FusionX_MZ2000.png' height='80%' width='100%' style="margin-left: auto; margin-right: auto; display: block;"/>
|
||
</div>
|
||
</div>
|
||
|
||
--------------------------------------------------------------------------------------------------------
|
||
|
||
###### <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 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.
|
||
<div style="padding-top: 0.8em;"></div>
|
||
|
||
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 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.
|
||
<div style="padding-top: 0.8em;"></div>
|
||
|
||
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 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>
|
||
|
||
<font style="color: cyan;" size="4">MZ-80A Video Interface Schematic</font>
|
||
|
||
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
|
||
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>
|
||
|
||
|
||
|
||
<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 existing internal cabling.
|
||
</div>
|
||
|
||
<div style='content: ""; clear: both; display: table;'>
|
||
<div style='width: 47%; padding: 5px; padding-left: 1em; float: left'>
|
||
<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='../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;">
|
||
|
||
|
||
</div>
|
||
|
||
--------------------------------------------------------------------------------------------------------
|
||
|
||
## <font style="color: yellow;" size="5">Reference Sites</font>
|
||
|
||
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
|
||
The table below contains all the sites referenced in the design and programming of the tran<i>ZPU</i>ter<sup><i>FusionX</i></sup>
|
||
</div>
|
||
|
||
<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>
|
||
<th>Site</th>
|
||
<th>Language</th>
|
||
<th>Description</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td><a href="https://github.com/redcode/Z80">Z80 Emulation</a></td>
|
||
<td>English</td>
|
||
<td>A highly accurate Z80 Emulation written in C, the heart of the FusionX.</td>
|
||
</tr>
|
||
<tr>
|
||
<td><a href="https://whycan.com/t_6006.html">WhyCan Forum</a></td>
|
||
<td>Chinese</td>
|
||
<td>Invaluable Forum with threads on SigmaStar products.</td>
|
||
</tr>
|
||
<tr>
|
||
<td><a href="http://doc.industio.com/docs/ssd20x-system/page_0">SSD20X System Development Manual</a></td>
|
||
<td>Chinese</td>
|
||
<td>System development manual for the SSD20X CPU.</td>
|
||
</tr>
|
||
<tr>
|
||
<td><a href="https://wx.comake.online/doc/d8clf27cnes2-SSD20X/customer/development/arch/arch.html">SigmaStarDocs</a></td>
|
||
<td>Chinese</td>
|
||
<td>SDK and API development manual.</td>
|
||
</tr>
|
||
<tr>
|
||
<td><a href="http://doc.industio.com/docs/ido-som2d0x-start/ido-som2d0x-start-1ctpf8rg06ct0">SOM2D0X Beginners Guide</a></td>
|
||
<td>Chinese</td>
|
||
<td>Beginners Guide to the SOM2D0X.</td>
|
||
</tr>
|
||
<tr>
|
||
<td><a href="https://github.com/civetweb/civetweb/blob/master/docs/UserManual.md">CivetWeb Users Manual</a></td>
|
||
<td>English</td>
|
||
<td>User Manual for the CivetWeb Embedded Web Server.</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</font></div>
|
||
|
||
--------------------------------------------------------------------------------------------------------
|
||
|
||
## <font style="color: yellow;" size="5">Manuals and Datasheets</font>
|
||
|
||
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
|
||
The table below contains all the datasheets and manuals referenced in the design and programming of the tran<i>ZPU</i>ter<sup><i>FusionX</i></sup>
|
||
</div>
|
||
|
||
<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>
|
||
<th>Datasheet</th>
|
||
<th>Language</th>
|
||
<th>Description</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td><a href="/Downloads/ADV7123_Datasheet.pdf">ADV7123</a></td>
|
||
<td>English</td>
|
||
<td>Original 5V 30bit VideoDAC (discontinued)</td>
|
||
</tr>
|
||
<tr>
|
||
<td><a href="/Downloads/GOTECOM-GM7123_VideoDAC.pdf">GM7123</a></td>
|
||
<td>Chinese</td>
|
||
<td>Chinese 3.3V version of the ADV7123 30bit VideoDAC converter.</td>
|
||
</tr>
|
||
<tr>
|
||
<td><a href="/Downloads/CH340E_Datasheet.pdf">CH340E</a></td>
|
||
<td>Chinese</td>
|
||
<td>USB to Serial UART converter.</td>
|
||
</tr>
|
||
<tr>
|
||
<td><a href="/Downloads/EPM7512AEQFP144_Datasheet.pdf">EPM7512AEQFP144</a></td>
|
||
<td>English</td>
|
||
<td>Altera 512 MacroCell 5V tolerant CPLD.</td>
|
||
</tr>
|
||
<tr>
|
||
<td><a href="/Downloads/HXJ8002_Datasheet.pdf">HXJ8002</a></td>
|
||
<td>English</td>
|
||
<td>Class D power amplifier.</td>
|
||
</tr>
|
||
<tr>
|
||
<td><a href="/Downloads/IDO_SOM2D01_Datasheet_EN.pdf">SOM2D01</a></td>
|
||
<td>English</td>
|
||
<td>SigmaStar SOM Datasheet (original model).</td>
|
||
</tr>
|
||
<tr>
|
||
<td><a href="/Downloads/REF3040_Datasheet.pdf">REF3040</a></td>
|
||
<td>English</td>
|
||
<td>Precise 4V reference voltage generator.</td>
|
||
</tr>
|
||
<tr>
|
||
<td><a href="/Downloads/SY6280_Datasheet.pdf">SY6280</a></td>
|
||
<td>English</td>
|
||
<td>Power distribution switch, used for enabling and supplying USB Bus power.</td>
|
||
</tr>
|
||
<tr>
|
||
<td><a href="/Downloads/TLC5602C_Datasheet.pdf">TLC5602C</a></td>
|
||
<td>English</td>
|
||
<td>8bit VideoDAC converter.</td>
|
||
</tr>
|
||
<tr>
|
||
<td><a href="/Downloads/TLV62569_Datasheet.pdf">TLV62569</a></td>
|
||
<td>English</td>
|
||
<td>High efficiency Buck Converter.</td>
|
||
</tr>
|
||
<tr>
|
||
<td><a href="/Downloads/TMUX1134_Datasheet.pdf">TMUX1134</a></td>
|
||
<td>English</td>
|
||
<td>Precision SPDT Analogue switch (Mux).</td>
|
||
</tr>
|
||
<tr>
|
||
<td><a href="/Downloads/ESD_Diode_vcut0714bhd1.pdf">VCUT0714BHD1</a></td>
|
||
<td>English</td>
|
||
<td>ESD Protection Diode.</td>
|
||
</tr>
|
||
<tr>
|
||
<td><a href="/Downloads/SigmaStar_USB_Programmer.docx">USB Programmer</a></td>
|
||
<td>English</td>
|
||
<td>SigmaStar USB Programmer for SSD202 Processor.</td>
|
||
</tr>
|
||
<tr>
|
||
<td><a href="/Downloads/SSD201_HW_Checklist_V10.xlsx">SSD201 HW Checklist v10</a></td>
|
||
<td>English</td>
|
||
<td>SigmaStar SSD201 Hardware Checklist.</td>
|
||
</tr>
|
||
<tr>
|
||
<td><a href="/Downloads/SSD202D_Reference_v04.pdf">SSD202D Reference v04</a></td>
|
||
<td>English</td>
|
||
<td>SigmaStar SSD202 CPU Reference Manual.</td>
|
||
</tr>
|
||
<tr>
|
||
<td><a href="/Downloads/IDO_SOM2D02_Pinout.xlsx">SOM2D02_Pinout</a></td>
|
||
<td>English</td>
|
||
<td>SigmaStar SOM2D02 Pinout.</td>
|
||
</tr>
|
||
<tr>
|
||
<td><a href="/Downloads/Z80_UserManual.pdf">Z80 UserManual</a></td>
|
||
<td>English</td>
|
||
<td>Z80 User Manual.</td>
|
||
</tr>
|
||
<tr>
|
||
<td><a href="/Downloads/SSD202D_ProductBrief_v01.pdf">SSD202D Product Brief</a></td>
|
||
<td>English</td>
|
||
<td>SigmaStar SSD202 CPU Product Brief.</td>
|
||
</tr>
|
||
<tr>
|
||
<td><a href="/Downloads/IDO_SOM2D01_Datasheet_EN.pdf">SOM2D01 Datasheet</a></td>
|
||
<td>English</td>
|
||
<td>SigmaStar SOM2D01 Datasheet.</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</font></div>
|
||
|
||
--------------------------------------------------------------------------------------------------------
|
||
|
||
<a name="project-preview" id="project-preview"></a>
|
||
## <font style="color: yellow;" size="6">Project Preview</font>
|
||
|
||
<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://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>— 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>— 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>— 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">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.
|
||
</div>
|
||
|
||
--------------------------------------------------------------------------------------------------------
|
||
|
||
## <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 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.
|
||
</div>
|
||
|
||
--------------------------------------------------------------------------------------------------------
|
||
|
||
## <font style="color: yellow;" size="5">The Gnu Public License v3</font>
|
||
|
||
<div style="text-align: justify; line-height: 1.4em; font-size: 0.8em; font-family:sans-serif;">
|
||
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.
|
||
<br><br>
|
||
|
||
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.
|
||
<br><br>
|
||
|
||
You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/.
|
||
</div>
|
||
|
||
--------------------------------------------------------------------------------------------------------
|