tranZPUter SW-700

Foreword

The initial release for the v1.3 hardware under the Git branch v2.2-tranZPUter-SW-HW_700_v1.3 targetted a Sharp MZ-700 host which significantly upgraded the machine in terms of features and functionality which has proved reliable and quite mature.

Recently I have ported the tranZPUter SW-700 project onto a Sharp MZ-2000 and upgraded the VHDL significantly to provide not only an MZ-2000 compatible Video mode but also inclusion of the Sharp MZ Series FPGA Emulation. The changes were significant requiring underlying structural changes to the CPLD and VHDL logic, a video signal daughterboard adapter (prototype pictured below) and updates to the Video Controller to support the MZ-2000 graphics logic.

Overview

tranZPUter SW-700

Hardware

v1.2 Schematics

Version 1.2 is the first official release of the tranZPUter SW-700 design. It is based around the Sharp MZ-80A tranZPUter SW v2.2 and the Video Module v2.0 with optimisations to fit the Sharp MZ-700 platform.

v1.2 Z80 Upgrade Schematic

v1.2 The K64 I/O Processor

v1.2 JTAG Programming and Oscillator

v1.2 Power Supply

v1.2 Video Interface

v1.2 PCB

v1.3 Schematics

Version 1.3 takes the working design of v1.2 and changes the FPGA to a more advanced component, the Cyclone IV EP4CE75, a 75K Logic Element device with over 340KB Block RAM. A build time option can use the Cyclone IV EP4CE115, a 115K Logic Element device with over 480K Block RAM. These devices allows for more advanced graphics, higher resolution and more simultaneous colours. It also allows for the creation of ‘soft’ HDL based CPU’s and is a stepping stone to the next iteration of the original ZPU based tranZPUter which will be based entirely on FPGA’s (ie. no Z80, just a Z80 extender socket with the Z80 instantiated as a soft-cpu in the FPGA).

v1.3 Z80 Upgrade Schematic

v1.3 The K64 I/O Processor

v1.3 JTAG Programming and Oscillator

v1.3 Power Supply

v1.3 Video Interface

v1.3 PCB

Design Detail

K64F Z80 Host API

// Structure to contain inter CPU communications memory for command service processing and results.
// Typically the z80 places a command into the structure in it's memory space and asserts an I/O request,
// the K64F detects the request and reads the lower portion of the struct from z80 memory space, 
// determines the command and then either reads the remainder or writes to the remainder. This struct
// exists in both the z80 and K64F domains and data is sync'd between them as needed.
//
typedef struct __attribute__((__packed__)) {
    uint8_t                          cmd;                                // Command request.
    uint8_t                          result;                             // Result code. 0xFE - set by Z80, command available, 0xFE - set by K64F, command ack and processing. 0x00-0xF0 = cmd complete and result of processing.
    union {
        uint8_t                      dirSector;                          // Virtual directory sector number.
        uint8_t                      fileSector;                         // Sector within open file to read/write.
        uint8_t                      vDriveNo;                           // Virtual or physical SD card drive number.
    };
    union {
        struct {
            uint16_t                 trackNo;                            // For virtual drives with track and sector this is the track number
            uint16_t                 sectorNo;                           // For virtual drives with track and sector this is the sector number. NB For LBA access, this is 32bit and overwrites fileNo/fileType which arent used during raw SD access.
        };
        uint32_t                     sectorLBA;                          // For LBA access, this is 32bit and used during raw SD access.
        struct {
            uint8_t                  memTarget;                          // Target memory for operation, 0 = tranZPUter, 1 = mainboard.
            uint8_t                  spare1;                             // Unused variable.
            uint16_t                 spare2;                             // Unused variable.
        };
    };
    uint8_t                          fileNo;                             // File number of a file within the last directory listing to open/update.
    uint8_t                          fileType;                           // Type of file being processed.
    union {
        uint16_t                     loadAddr;                           // Load address for ROM/File images which need to be dynamic.
        uint16_t                     saveAddr;                           // Save address for ROM/File images which need to be dynamic.
        uint16_t                     cpuFreq;                            // CPU Frequency in KHz - used for setting of the alternate CPU clock frequency.
    };
    union {
        uint16_t                     loadSize;                           // Size for ROM/File to be loaded.
        uint16_t                     saveSize;                           // Size for ROM/File to be saved.
    };
    uint8_t                          directory[TZSVC_DIRNAME_SIZE];      // Directory in which to look for a file. If no directory is given default to MZF.
    uint8_t                          filename[TZSVC_FILENAME_SIZE];      // File to open or create.
    uint8_t                          wildcard[TZSVC_WILDCARD_SIZE];      // A basic wildcard pattern match filter to be applied to a directory search.
    uint8_t                          sector[TZSVC_SECTOR_SIZE];          // Sector buffer generally for disk read/write.
} t_svcControl;

API Command List

API Result List

K64F GPIO Organisation

K64F Port and Bit allocation

GPIO bits to Z80 Address Line mapping

GPIO bits to Z80 Data Line mapping

Z80 Memory Modes

MZ700/MZ800 Memory Mode

Z80 CPU Frequency Switching

• tranZPUter reliable in the range 1Hz to 24MHz for all functionality.
• When the mainboard is accessed the frequency slows to 3.54MHz (ie. the system clock) and returns to the higher frequency after the mainboard access has completed.

Z80 CPU Frequency Switching Ports

System Configuration

The CPLD holds an internal configuration register to change how it operates with the underlying host. The table below outlines the ports along with each bits function.

System Configuration Register (0x6E - 110 decimal)

NB: The compatibility modes which have been implemented appear in the paragraphs below, all other modes are yet to be implemented. Selecting a mode which hasnt been implemented results in no mapping and reverts to the base MZ-700 hardware.

The CPLD also holds a read only information register which indicates the capabilities of the running machine.

System Information Register (0x6F - 111 decimal)

The CPLD contains some basic command functionality to aid with fine control of the underlying host. The commands are initiated via a write to the CPLD command register.

System Command Register (0x6B - 107 decimal)

Soft Processors

The second processor added is the ZPU Evolution, a 32bit stack based processor originally written by Øyvind Harboe from Zylin AS as a minimal logic size CPU to run in a supervisory mode in embedded systems. There have been a few extensions to the design, the ZPU Flex and ZPUINO of note, but both didnt offer what I wanted for embedding into the Sharp MZ Series Emulator, so I redesigned it to gain speed and expandability creating the ZPU Evolution.

As the ZPU Evolution was intended to be embedded, zOS was written with this functionality in mind, an OS which would run tasks inside a device to enhance it’s functionality along with provision of an interactive session over a serial connection. Using a console connected to the serial connection you would be presented with an MS-DOS like environment where you could run applications, control hardware or inspect/update memory and process flow, an ideal tool to work with a ‘soft’ ZPU Evolution running inside an FPGA which in turn was running inside an end application such as the Sharp MZ Series Emulator. When the tranZPUter SW project was born, zOS was ported to the K64F which has been a great asset, being able to connect inside the tranZPUter SW and the Sharp MZ host has aided design and debug immensely.

Adding a ZPU Evo into the tranZPUter SW-700 as a ‘soft’ processor required zOS to evolve, it no longer had serial connectivity and was required to control keyboard, screen etc directly. This led to the SharpMZ module being added which provides zOS with the basic hardware abstraction layers to drive the Sharp MZ-700 keyboard and screen, providing the basic user I/O functionality including an ANSI terminal emulator. When the ZPU is selected from the Sharp MZ-700 monitor, zOS boots and you are presented with an interactive, MS-DOS like environment. There are some basic applications such as tbasic, mbasic. kilo (a VT100 based screen editor) and these can all be found in the apps section of zOS. As can be imagined, there isnt a lot of software to be run under zOS, although a lot of open source projects can be ported, the limiting factor is the GNU C/C++ 99 standard compiler or missing features such as thread control and virtual memory.

I am currently looking at instantiating a NIOSII processor with MMU as the FPGA has the resources to implement this processor and its support circuits and the end result would be Linux running on a Sharp MZ-700. This would be a far more useful platform so consider this is work in progress until completed and this page updated.

CPU Configuration Registers

CPU Configuration Register (0x6C - 108 decimal)

The FPGA holds a read only information register which indicates the soft processor capabilities.

CPU Information Register (0x6D - 109 decimal)

ZPU Memory Map.

The ZPU has a configurable linear address space, typically 18-32 bit wide. When used as a soft processor it is configured for 24bit.

Video Module

Programmable Registers

In order to make use of the video functionality a set of registers have been designed through which all functions can be accessed.

The functionality is grouped as follows:

• Control - set the video capability mode, set the column width, set the colour/mono capabilities.
• Graphics - configure the graphics capability.
• GPU - offload tasks to the inbuilt graphics processor to speed up video tasks.
• Palette - set and configure the display palette.

The registers lie in the upper I/O region from 0xD0 - 0XFD and are accessed with standard Z80 I/O commands IN/OUT. Unless otherwise stated, all registers are read/write and a read will return the current value stored.

Control Register (0xA8 - 168 decimal)

This is the video mode register. It specifies the hardware model the Video Module should function as in addition the column width and colour abilities of the output display.

Graphics Mode Register (0xA9 - 169 decimal)

This is the graphics mode control register. It specifies what video is to be output, how it is blended and which Graphics RAM bank can be read/written to.

Colour Writer Registers (0xAA - 170 decimal to 0xAC - 172 decimal)

Memory Page Registers (0xAD - 173 decimal)

This register is responsible for enabling Video memory into Z80 address space. It is possible to enable 1 of the 3 colour 16KB GRAM (chosen via the Graphics Mode register) into Z80 address C000:FFFF or the CGROM into Z80 address space D000:DFFF. This register overrides all other memory page settings.

Video Module Status Register (0xAD - 173 decimal)

This register reports on the Video Module status. Bits 7 & 0 are reserved for reporting the Memory Page register settings.

GPU Parameters Register (0xB2 - 178 decimal)

GPU Command Register (0xB3 - 179 decimal)

GPU Status Register (0xB3 - 179 decimal)

This register returns the current GPU status and should be polled before each new command is requested.

VGA Border Area and Attribute Register (0xBE - 190 decimal)

In VGA modes, the expansion of the graphics RAM/VRAM doesnt quite fill the entire display area which is normally left blank. This register allows attributes to be set so that different colours can be applied as needed.

VGA Mode Register (0xBF - 191 decimal)

VGA Mode register, sets output resolution and frequency on external display.

Select Palette Register (0xB0 - 176 decimal)

Select Palette Configration Off Pointer Register (0xA3 - 163 decimal)

This register sets the palette number to be configured when a pixel (R/G/B) is in the off state. ie. colour to be output when the pixels are off. A write to this register is made prior to writing into the actual palette colour registers.

Select Palette Configration On Pointer Register (0xA4 - 164 decimal)

This register sets the palette number to be configured when a pixel (R/G/B) is in the on state. ie. colour to be output when the pixels are on. A write to this register is made prior to writing into the actual palette colour registers.

Set Palette Red Value Register (0xA5 - 165 decimal)

This register sets the 5 bit Red value to be used in the palette selected via The Off/On Pointer Registers.

Set Palette Green Value Register (0xA6 - 166 decimal)

This register sets the 5 bit Green value to be used in the palette selected via The Off/On Pointer Registers.

Set Palette Blue Value Register (0xA7 - 167 decimal)

This register sets the 5 bit Blue value to be used in the palette selected via The Off/On Pointer Registers.

Set Video Mode Parameter Register (0xA0 - 160 decimal)

Set Video Mode Lower Parameter Byte Register (0xA1 - 161 decimal)

This register is used to write the lower byte of the parameter selected with the Video Mode Parameter Register. ie. If Parameter 0 is set, then a write to this register will update the lower byte of the H_DSP_START parameter.

Set Video Mode Upper Parameter Byte Register (0xA2 - 162 decimal)

This register is used to write the upper byte of the parameter selected with the Video Mode Parameter Register. ie. If Parameter 0 is set, then a write to this register will update the upper byte of the H_DSP_START parameter.

Direct Access Mode

The Video Controller has a direct access mode using a 24bit address which bypasses the CPLD memory manager. This mode can be used by the K64F I/O processor or a soft processor instantiated on the FPGA. In the table below, Y refers to the address offset, for the ZPU configuration this would be 0xE00000.

Compatibility Modes

Hardware Description Language

Complex Logic Device - MAX 7000A

The CPLD replaces the discreet logic and Flash RAM decoder found on the original tranZPUter SW. It interfaces directly with the Z80 signals from the Sharp MZ-700 and the tranZPUter Z80 upgrade logic. It’s purpose is to provide

• Z80 Memory Map decoding
• Z80 BUS control
• Bi-directional BUS control allowing a processor inside the FPGA to control the underlying host hardware.
• WAIT State generation
• Hardware remapping
• Voltage translation

The source files which form the CPLD configuration are:

<host> = MZ700 - HDL for tranZPUter SW-700 running on a Sharp MZ-700 host.
               = MZ2000 - HDL for tranZPUter SW-700 running on a Sharp MZ-2000 host.

Building the CPLD bitstream

Compilation:

   1. Start Quartus Prime v13.0.1, either your local installation or a Docker image.
   2. Go to 'File->Open Project' and search for the directory where your repository clone is stored then select the file in <Clone Path>/tranZPUter/CPLD/build/tranZPUterSW700.qpf, this will open the CPLD tranZPUter SW-700 project.
   3. Select 'Processing->Start' Compilation - you can safely ignore the warning messages.
   4. When completed, a bitstream will have been created with the name: tranZPUterSW700.sof in the <Clone Path>/tranZPUter/CPLD/build/output_files directory.

Programming:

   1. To upload the bitstream into the CPLD, you need an Altera USB Blaster connected via USB port to the 10pin JTAG IDC connector on the tranZPUter SW-700 board.
   2. In Quartus Prime, go to 'Tools->Programmer' which will start a new Programmer window.
   3. In the Programmer window, click on 'Hardware Setup' and choose your USB adapter and then 'Close'
   4. Click on 'Auto Detect' and it should find 3 devices, an EPM7512AET144, an EP3C25E144 and an EPCS16.
   5. Right click on the EPM7512AET144 device, select Add File then choose the sof file located in <Clone Path>/tranZPUter/CPLD/build/output_files/tranZPUterSW700.sof and click Open.
   6. Select 'Program/Configure' and 'Verify' tick boxes against the EPM7512AET144.
   7. Click on 'Start' and the CPLD should be programmed with the compiled bitstream.

Field Programmable Gate Array

Using a soft ZPU processor, the zOS operating system acts as the host operating system on the MZ-700 console and zOS also acts as the embedded operating system in the ARM Cortex-M4 K64F I/O processor.

FPGA Version 1.2 - Cyclone III

The Cyclone III FPGA in version 1.2 of the tranZPUter SW-700 hardware provides enhanced video capabilities for the Sharp MZ-700. Using the Sharp MZ Emulator as it’s base, it is able to provide nearly all of the Sharp MZ video hardware capabilities along with colour pixel mapped graphics. It also provides the fledgling start of a GPU (Graphics Processing Unit). The FPGA provides:

• Video capabilities of the Sharp MZ machines: MZ-80K, MZ-80C, MZ-1200, MZ-80A, MZ-700, MZ-80B (including GRAM I/II).
• Colour pixel graphics modes, 8 colour 640x200 and 320x200.
• Multiple video output modes, ie: Original, VGA 640x480@60Hz, VGA 800x600@60Hz, VGA 1024x768@60Hz.

Building the FPGA v1.2 bitstream

Compilation:

   1. Start Quartus Prime v13.1, either your local installation or a Docker image.
   2. Go to 'File->Open Project' and search for the directory where your repository clone is stored then select the file in <Clone Path>/tranZPUter/FPGA/SW700/v1.2/build/VideoController700.qpf, this will open the FPGA tranZPUter SW-700 project.
   3. Select 'Processing->Start Compilation' - you can safely ignore the warning messages.
   4. When completed, a bitstream will have been created with the name: VideoController700.sof in the <Clone Path>/tranZPUter/FPGA/SW700/v1.2/build/output_files directory.

Programming FPGA:

   1. To upload the bitstream into the FPGA, you need an Altera USB Blaster connected via USB port to the 10pin JTAG IDC connector on the tranZPUter SW-700 board.
   2. In Quartus Prime, go to 'Tools->Programmer' which will start a new Programmer window.
   3. In the Programmer window, click on 'Hardware Setup' and choose your USB adapter and then 'Close'
   4. Click on 'Auto Detect' and it should find 3 devices, an EPM7512AET144, an EP3C25E144 and an EPCS16.
   5. Right click on the EP3C25E144 device, select 'Edit->Add File' then choose the sof file located in <Clone Path>/tranZPUter/FPGA/SW700/v1.2/build/output_files/VideoController700.sof and click Open.
   6. Select 'Program/Configure' tick box against the EP3C25E144.
   7. Click on 'Start' and the FPGA should be programmed with the compiled bitstream.
   8. The programming of the FPGA is not persistent, when powered off it will lose the bitmap. To make the programming persistent, following the instructions below to program the EPCS16.

Programming EPCS16:

   1. To upload the bitstream into the EPCS16, a non-volative serial Flash RAM which the FPGA reads on power up you will  need an Altera USB Blaster connected via USB port to the 10pin JTAG IDC connector on the tranZPUter SW-700 board.
   2. In Quartus Prime, go to 'File->Convert Programming Files' which will start a new 'Convert Programming File' window.
   3. In the Convert Programming File window:
     3a. Click on 'Programming File Type' and select JTAG Indirect Configuration File.
     3b. Click on 'Configuration Device' and select EPCS16.
     3c. Click on 'File Name' and choose <Clone Path>/tranZPUter/FPGA/SW700/v1.2/build/output_files/VideoController700.sof.
     3d. Click on 'Flash Loader' then click on 'Add Device' button. Select Cyclone III -> EP3C25, click on OK.
     3e. Click on 'SOF Data', then click on 'Add File' button. Select the output file which will be <Clone Path>/tranZPUter/FPGA/SW700/v1.2/build/output_files/VideoController700.jic, click on OK.
     3f. Click on the 'Generate' button, the output JIC file will now be created as <Clone Path>/tranZPUter/FPGA/SW700/v1.2/build/output_files/VideoController700.jic
     3g. Click on 'Close' to close the Convert Programming File window.
   4. In Quartus Prime, go to 'Tools->Programmer' which will start a new Programmer window.
   5. In the Programmer window, click on 'Hardware Setup' and choose your USB adapter and then 'Close'
   6. Click on 'Auto Detect' and it should find 3 devices, an EPM7512AET144, an EP3C25E144 and an EPCS16.
   7. Right click on the EP3C25E144 device, select 'Edit->Add File' then choose the sof file located in <Clone Path>/tranZPUter/FPGA/SW700/v1.2/build/output_files/VideoController700.sof and click Open.
   8. Right click on the EPCS16 device, select 'Edit->Add File' then choose the jic file located in <Clone Path>/tranZPUter/FPGA/SW700/v1.2/build/output_files/VideoController700.jic and click Open.
   9. Select 'Program/Configure' tick box against the EP3C25E144.
  10. Select 'Program/Configure' and 'Verify' tick boxes against the EPCS16.
  11. Click on 'Start' and the FPGA and the EPCS16 non-volatile Flash RAM should be programmed with the compiled bitstream.
  12. The programming of the FPGA is now persistent and will persist across power cycles.

FPGA Version 1.3 - Cyclone IV

The Cyclone IV FPGA in version 1.3 of the tranZPUter SW-700 hardware provides not only the enhanced video capabilities of the version 1.2 board for the Sharp MZ-700 but also a set of soft CPU’s, ie. the ZPU EVO(lution). This FPGA provides:

• Video capabilities of the Sharp MZ machines: MZ-80K, MZ-80C, MZ-1200, MZ-80A, MZ-700, MZ-800, MZ-80B (inc GRAM I/II) and MZ-2000 (inc GRAM I/II/III).
• Colour pixel graphics modes, 8 colour 640x400, 640x200 and 320x200.
• Multiple video output modes, ie: Original 50Hz, Original 60Hz, VGA 640x480@60Hz, VGA 800x600@60Hz.
• The T80 Soft CPU, a Z80 compatible processor written in VHDL.
• The ZPU EVO(lution) Soft CPU, a 32bit stack based processor running the zOS operating system.
• The Sharp MZ Series FPGA Emulation providing hardware emulation of all Sharp MZ machines from the MZ-80K upto MZ-2200.

Building the FPGA v1.3 bitstream

Compilation:

   1. Start Quartus Prime v17.1, either your local installation or a Docker image.
   2. Go to 'File->Open Project' and search for the directory where your repository clone is stored then select the file in <Clone Path>/tranZPUter/FPGA/SW700/v1.3/build/coreMZ.qpf, this will open the FPGA tranZPUter SW-700 project.
   3. Select 'Processing->Start Compilation' - you can safely ignore the warning messages.
   4. When completed, a bitstream will have been created with the name: VideoController700.sof in the <Clone Path>/tranZPUter/FPGA/SW700/v1.3/build/output_files directory.

Programming FPGA:

   1. To upload the bitstream into the FPGA, you need an Altera USB Blaster connected via USB port to the 10pin JTAG IDC connector on the tranZPUter SW-700 board.
   2. In Quartus Prime, go to 'Tools->Programmer' which will start a new Programmer window.
   3. In the Programmer window, click on 'Hardware Setup' and choose your USB adapter and then 'Close'
   4. Click on 'Auto Detect' and it should find 3 devices, an EPM7512AET144, an EP4CE75F23 and an EPCS64.
   5. Right click on the EP3C25E144 device, select 'Edit->Add File' then choose the sof file located in <Clone Path>/tranZPUter/FPGA/SW700/v1.3/build/output_files/coreMZ.sof and click Open.
   6. Select 'Program/Configure' tick box against the EP4CE75F23.
   7. Click on 'Start' and the FPGA should be programmed with the compiled bitstream.
   8. The programming of the FPGA is not persistent, when powered off it will lose the bitmap. To make the programming persistent, following the instructions below to program the EPCS54.

Programming EPCS16:

   1. To upload the bitstream into the EPCS16, a non-volative serial Flash RAM which the FPGA reads on power up you will  need an Altera USB Blaster connected via USB port to the 10pin JTAG IDC connector on the tranZPUter SW-700 board.
   2. In Quartus Prime, go to 'File->Convert Programming Files' which will start a new 'Convert Programming File' window.
   3. In the Convert Programming File window:
     3a. Click on 'Programming File Type' and select JTAG Indirect Configuration File.
     3b. Click on 'Configuration Device' and select EPCS64.
     3c. Click on 'File Name' and choose <Clone Path>/tranZPUter/FPGA/SW700/v1.3/build/output_files/coreMZ.sof.
     3d. Click on 'Flash Loader' then click on 'Add Device' button. Select Cyclone IV -> EP4CE75, click on OK.
     3e. Click on 'SOF Data', then click on 'Add File' button. Select the output file which will be <Clone Path>/tranZPUter/FPGA/SW700/v1.3/build/output_files/coreMZ.jic, click on OK.
     3f. Click on the 'Generate' button, the output JIC file will now be created as <Clone Path>/tranZPUter/FPGA/SW700/v1.3/build/output_files/coreMZ.jic
     3g. Click on 'Close' to close the Convert Programming File window.
   4. In Quartus Prime, go to 'Tools->Programmer' which will start a new Programmer window.
   5. In the Programmer window, click on 'Hardware Setup' and choose your USB adapter and then 'Close'
   6. Click on 'Auto Detect' and it should find 3 devices, an EPM7512AET144, an EP4CE75F23 and an EPCS64.
   7. Right click on the EP3C25E144 device, select 'Edit->Add File' then choose the sof file located in <Clone Path>/tranZPUter/FPGA/SW700/v1.3/build/output_files/coreMZ.sof and click Open.
   8. Right click on the EPCS16 device, select 'Edit->Add File' then choose the jic file located in <Clone Path>/tranZPUter/FPGA/SW700/v1.3/build/output_files/coreMZ.jic and click Open.
   9. Select 'Program/Configure' tick box against the EP4CE75F23.
  10. Select 'Program/Configure' and 'Verify' tick boxes against the EPCS64.
  11. Click on 'Start' and the FPGA and the EPCS64 non-volatile Flash RAM should be programmed with the compiled bitstream.
  12. The programming of the FPGA is now persistent and will persist across power cycles.

Quartus Prime in Docker

1. Clone the repository:

    cd ~
    git clone https://github.com/pdsmart/zpu.git
    cd zpu/docker/QuartusPrime
   

   
   Current configuration will build a Lite version of Quartus Prime. If you want to install the Standard version, before building the docker image:

    Edit:        zpu/docker/QuartusPrime/Dockerfile.13.0.1
    Uncomment:   '#ARG QUARTUS=QuartusSetup-13.0.1.232.run'
    Comment out: 'ARG QUARTUS=QuartusSetupWeb-13.0.1.232.run'
   

   If you have a license file:

    Copy: <your license file> to zpu/docker/QuartusPrime/files/license.dat
    Edit:  zpu/docker/QuartusPrime/run.sh
    Change: MAC_ADDR="02:50:dd:72:03:01" so that is has the MAC Address of your license file.
   

   Build the docker image:

    docker build -f Dockerfile.13.0.1 -t quartus-ii-13.0.1 --build-arg user_uid=`id -u`  --build-arg user_gid=`id -g` --build-arg user_name=`whoami` .
   

   
   For Quartus Prime 13.1 or 17.1.1 replace 13.0.1 with the necessary version. Quartus Prime 13.0.1 supports the older MAX CPLD devices. Quartus Prime 13.1 supports the older Cyclone III devices and 17.1.1 supports the Cyclone IV devices.

2. Setup your X DISPLAY variable to point to your xserver:

    export DISPLAY=<x server ip or hostname>:<screen number or :<screen number>>
    # ie. export DISPLAY=192.168.1.1:0
   

   On your X server machine, issue the command:

    xhost +
    # or xhost <ip of docker host> to maintain security on a non private network.
   

3. Setup your project directory accessible to Quartus.

    Edit:        zpu/docker/QuartusPrime/run.sh
    Change:      PROJECT_DIR_HOST=<location on your host you want to access from Quartus Prime>
    Change:      PROJECT_DIR_IMAGE=<location in Quartus Prime running container to where the above host directory is mapped>
    # ie. PROJECT_DIR_HOST=/srv/quartus
          PROJECT_DIR_IMAGE=/srv/quartus
   

4. Run the image using the provided bash script ‘run_quartus.sh’. This script

    ./run_quartus.sh
   

   
   This will start Quartus Prime and also an interactive bash shell.
   On first start it currently asks for your license file, click 'Run the Quartus Prime software' and then OK.
   
   The host devices are mapped into the running docker container so that if you connect a USB Blaster it will be seen within the Programmer tool. As part of the installation I install the udev rules for USB-Blaster and USB-Blaster II as well as the Arrow USB-Blaster driver for use with the CYC1000 dev board.

5. To stop quartus prime:

    # Either exit the main Quartus Prime GUI window via File->Exit
    # or
    docker stop quartus
   

   
   

Software

zOS

Please see the section on zOS for details on the operating system. In addition to the standard features and tools, the following applications have been added:

TZLOAD v1.2

Commands:-
  -h | --help              This help text.
  -d | --download <file>   File into which memory contents from the tranZPUter are stored.
  -u | --upload   <file>   File whose contents are uploaded into the traZPUter memory.
  -U | --uploadset <file>:<addr>,...,<file>:<addr>
                           Upload a set of files at the specified locations. --mainboard specifies mainboard is target, default is tranZPUter.
  -V | --video             The specified input file is uploaded into the video frame buffer or the specified output file is filled with the video frame buffe.

Options:-
  -a | --addr              Memory address to read/write.
  -l | --size              Size of memory block to read. This option is only used when reading tranZPUter memory, for writing, the file size is used.
  -s | --swap              Read tranZPUter memory and store in <infile> then write out <outfile> to the same memory location.
  -f | --fpga              Operations will take place in the FPGA memory. Default without this flag is to target the tranZPUter memory.
  -m | --mainboard         Operations will take place on the MZ80A mainboard. Default without this flag is to target the tranZPUter memory.
  -M | --mempage           Operations on mainboard will page in all DRAM banks prior to operation. ie. MZ-700 will page in lower and upper DRAM banks so 0000:FFFF = DRAM
  -z | --mzf               File operations are to process the file as an MZF format file, --addr and --size will override the MZF header values if needed.
  -v | --verbose           Output more messages.

Examples:
  tzload --download monitor.rom -a 0x000000      # Load the file monitor.rom into the tranZPUter memory at address 0x000000.

TZDUMP v1.1

Commands:-
  -h | --help              This help text.
  -a | --start             Start address.

Options:-
  -e | --end               End address (alternatively use --size).
  -s | --size              Size of memory block to dump (alternatively use --end).
  -f | --fpga              Operations will take place in the FPGA memory. Default without this flag is to target the tranZPUter memory.
  -m | --mainboard         Operations will take place on the MZ80A mainboard. Default without this flag is to target the tranZPUter memory.
  -v | --verbose           Output more messages.

Examples:
  tzdump -a 0x000000 -s 0x200   # Dump tranZPUter memory from 0x000000 to 0x000200.

TZCLEAR v1.1

Commands:-
  -h | --help              This help text.
  -a | --start             Start address.

Options:-
  -e | --end               End address (alternatively use --size).
  -s | --size              Size of memory block to clear (alternatively use --end).
  -b | --byte              Byte value to place into each cleared memory location, defaults to 0x00.
  -f | --fpga              Operations will take place in the FPGA memory. Default without this flag is to target the tranZPUter memory.
  -m | --mainboard         Operations will take place on the MZ80A mainboard. Default without this flag is to target the tranZPUter memory.
  -v | --verbose           Output more messages.

Examples:
  tzclear -a 0x000000 -s 0x200 -b 0xAA  # Clears memory locations in the tranZPUter memory from 0x000000 to 0x000200 using value 0xAA.

TZCLK v1.0

Commands:-
  -h | --help              This help text.
  -f | --freq              Desired CPU clock frequency.

Options:-
  -e | --enable            Enable the secondary CPU clock.
  -d | --disable           Disable the secondary CPU clock.
  -v | --verbose           Output more messages.

Examples:
  tzclk --freq 4000000 --enable  # Set the secondary CPU clock frequency to 4MHz and enable its use on the tranZPUter board.

TZRESET v1.0

Commands:-
  -h | --help              This help text.
  -r | --reset             Perform a hardware reset.
  -l | --load              Reload the default ROMS.
  -m | --memorymode <val>  Set the memory mode.

Options:-
  -v | --verbose           Output more messages.

Examples:
  tzreset -r        # Resets the Z80 and associated tranZPUter logic.

TZIO v1.1

Commands:-
  -h | --help              This help text.
  -o | --out <port>        Output to I/O address.
  -i | --in <port>         Input from I/O address.

Options:-
  -b | --byte              Byte value to send to the I/O port in the --out command, defaults to 0x00.
  -m | --mainboard         Operations will take place on the MZ80A mainboard. Default without this flag is to target the tranZPUter I/O domain.
  -v | --verbose           Output more messages.

Examples:
  tzio --out 0xf8 --byte 0x10    # Setup the FPGA Video mode at address 0xf8.

TZFLUPD v1.1

Commands:-
  -h | --help              This help text.
  -f | --file              Binary file to upload and flash into K64F.

Options:-
  -v | --verbose           Output more messages.

Examples:
  tzflupd -f zOS_22012021_001.bin --verbose   # Upload and program the zOS_22012021_001.bin file into the K64F flash memory.

TZMTEST v1.0

Commands:-
  -h | --help              This help text.
  -a | --start             Start address.

Options:-
  -e | --end               End address (alternatively use --size).
  -s | --size              Size of memory block to test (alternatively use --end).
  -f | --fpga              Operations will take place in the FPGA memory. Default without this flag is to target the tranZPUter memory.
  -i | --iter              Number of test iterations, default = 1.
  -t | --test              Specify test as a bit value, bit 0 = R/W inc ascending test, 1 = R/W inc walking test, 2 = W ascending then R,
                           bit 3 = W walking then R, bit 4 = echo and stick bit test.
  -v | --verbose           Output more messages.

Examples:
  tzmtest -a 0x000000 -s 0x20000   # Test 128K tranZPUter memory from 0x000000 to 0x020000.

TranZputer Filing System

The TranZputer Filing System is a port of the Rom Filing System used on the MZ-80A Rom Disk upgrade board. It reuses much of the same software functionality and consequently provides the same services, the differences lie in the use of a different memory model. It’s purpose is to provide methods to manipulate files stored on the SD card and provide an extended command line interface, the TZFS Monitor. The command set includes SD file manipulation and backup along with a number of commands found on the MZ700/800 computers.

Under RFS the software had to be split into many ROM pages and accessed via paging as necessary, the same is true for TZFS but the pages are larger and thus less pages are needed. The Z80 software which forms the TranZputer Filing System can be found in the repository within the <software> directory.

The following files form the TranZputer Filing System:

In addition there are several shell scripts to aid in the building of TZFS software, namely:

CP/M

The following files form the CBIOS and CP/M Operating System:

Additionally there are several shell scripts to aid in the building of the CP/M software, namely:

Please refer to the CP/M section for more details,

TZFS Monitor

JE800<cr>

It is possible to automate the startup of the computer directly into TZFS. To do this create an empty file in the root directory of the SD card called:

'TZFSBOOT.FLG'

For the directory listing commands, 4 columns of output will be shown when in 80 column mode.

Tape Commands

It is now possible to read and write all of the Sharp MZ Series tape formats through TZFS commands. This is a very useful feature if you own other MZ machines such as an MZ-80B where cassettes are not in plentiful supply yet the software programs are available as binary MZF images.

Tape Load

To load a tape into the MZ-700 memory, you can use the commands L, LT or LTNX. L and LT are identical, LTNX loads a program but doesnt execute it, rather reporting the load, size and execution address on completion.

To specify the machine of the source tape, use the <hardware mode> option after the command (default, if not present, is MZ-700).

ie. Loading a tape using the MZ-80B standard 1800 baud system you would issue the command:
    L,B

Tape Save

To save a tape from MZ-700 memory onto the MZ-700 CMT unit you can use the S or identical ST commands. You specify, as a continous command, the starting address (the location in MZ-700 memory your program resides), the end address (last address of your program) and the execution address. Currently you cannot specify the attribute which defaults to OBJCD or executable. On issuing the command you are prompted for a filename and the MZF header is then created and the program saved to tape.

To specify the machine of the target tape, use the <hardware mode> option after the command (default, if not present, is MZ-700).

ie. Saving a program at starting address $1200, ending at $3035 and execution address is $1200 generating a tape to be used on an MZ-80B you would issue the command:
    ST120030351200,B

Copy SD File To Tape

To copy an MZF file stored on the SD card onto a tape you would use the SD2T command. You would typically use the CD and DIR commands to locate the necessary file and then provide its unique number as an argument to the command.

To specify the machine of the target tape, use the <hardware mode> option after the command (default, if not present, is MZ-700).

ie. Assuming you wanted to copy BASIC MZ-1Z001 to tape for an MZ-2000 machine and the file had the SD card id ‘0C’, you would place a tape into the cassette drive, and issue the command:
    SD2T0C,2

Copy Tape To SD File

To copy a tape program onto an SD card you would use the T2SD command. You would typically use the CD commands to switch to the desired directory where the image will be stored (maximum file limit of 255 per directory) and execute this command. The command will then search the tape, load the first program found and save it to SD card using the filename of the tape image.

To specify the machine of the target tape, use the <hardware mode> option after the command (default, if not present, is MZ-700).

ie. Assuming you wanted to save an MZ-800 based program to SD card, you would load the tape into the drive and issue the command:
    T2SD,8
On completion the file details and SD card Id will be reported.

Bulk Copy Entire Tapes To SD

If you have a tape with multiple files stored or multiple tapes and you need to store them on SD, you would use the T2SDB command. This command is identical to the T2SD command above except it enters a loop reading from tape and saving to SD. Pressing BREAK at any time exits the command.

To specify the machine of the target tape, use the <hardware mode> option after the command (default, if not present, is MZ-700).

ie. Assuming you wanted to save an entire MZ-800 tape to SD card, you would load the tape into the drive and issue the command:
    T2SDB,8
As each file is read and saved the command will output the start, size and exec addresses along with the stored filename.

Sharp BASIC SA-5510

The new version of BASIC SA-5510 is named “BASIC SA-5510-TZ”.

NB: I havent yet fully implemented the random file read/write BASIC operations as I dont fully understand the logic. Once I get a suitable program I can analyse I will adapt TZFS so that it works according to the CMT specification.

Microsoft BASIC

There are two versions of the NASCOM 4.7b source code available on the internet, either the original or a version stripped of several hardware dependent commands such as LOAD /SAVE /SCREEN but tweaked to add binary/hex variables by Grant Searle for his multicomp project. I took both versions to make a third, writing and expanding on available commands including the missing tape commands.

• MS-BASIC(MZ-80A) - Original 48K hardware which can be booted from cassette.
• MS-BASIC(MZ-700) - Original 64K hardware which can be booted from cassette.
• MS-BASIC(TZFS40) - TZFS upgrade with no video upgrade hardware installed.
• MS-BASIC(TZFS80) - TZFS upgrade with a video module FPGA upgrade installed offering 80 column display.

Each appears on the TZFS drive and should be used according to hardware and need. The original NASCOM Basic Manual should be consulted for the standard set of commands and functions. The table below outlines additions which I have added to better suite the MZ-80A Rom Disk hardware.

NASCOM Cassette Image Converter Tool

The converter is designed to run on the command line and it’s synopsis is:

NASCONV v1.0

Required:-
  -i | --image <file>      Image file to be converted.
  -o | --output <file>     Target destination file for converted data.

Options:-
  -l | --loadaddr <addr>   MZ80A basic start address. NASCOM address is used to set correct MZ80A address.
  -n | --nasaddr <addr>    Original NASCOM basic start address.
  -h | --help              This help test.
  -v | --verbose           Output more messages.

Examples:
  nasconv --image 3dnc.cas --output 3dnc.bas --nasaddr 0x10fa --loadaddr 0x4341    Convert the file 3dnc.cas from NASCOM cassette format.

Building tranZPUter SW-700 Software

The tranZPUter SW-700 board requires several software components to function:

• zOS embedded - the integral operating system running on the K64F I/O processor
• zOS user - the operating system for a ZPU Evo running as the Sharp MZ-700 main host processor
• TZFS - the Z80 based operating or filing system running on the Sharp MZ-700
• CP/M - A real operating system for Microcomputers which I ported to the Sharp MZ-700 and it benefits from a plethora of applications.

Building the software requires different procedures and these are described in the sections below.

Paths

For ease of reading, the following shortnames refer to the corresponding path in this chapter. Two repositories are used, the primary one for the tranZPUter and zSoft for the operating system.

zSoft Repository (zOS)

tranZPUter Repository

Tools

NB: For the K64F, the ARM compatible toolchain is currently stored in the repo within the build tree.

Build zOS (embedded)

To build zOS as the embedded OS within the K64F I/O processor please refer to the zOS build section.

A typical build line would be:

build.sh -C K64F -O zos  -N 0x10000 -d -T

This builds a zOS image for the K64F processor with a primary heap of 64K (-N 0x10000) and adds the tranZPUter extensions (-T).

The output file would be <z-zOS>/main.hex which can be uploaded into the K64F CPU on the tranZPUter board.

Build zOS (user)

To build zOS as the user OS to run on a ZPU Evo acting as the main Sharp MZ-700 processor, please refer to the zOS build section for information on zOS and the details below to build.

Initially, in hardware, the ZPU Evo has 128K high speed 32bit RAM allocated in the FPGA and 512K 8bit RAM on the tranZPUter board. A typical build line would be:

build.sh -C EVO -O zos -o 0 -M 0x1FD80 -B 0x0000 -S 0x3D80 -N 0x4000 -A 0x100000 -a 0x80000 -n 0x0000 -s 0x0000 -d -Z

This builds a zOS image for the ZPU processor with a primary heap of 16K (-N 0x4000), stack of 15K (-S 0x3D80) and adds the SharpMZ hardware driver extensions (-Z). Things to note are the top of RAM limit -M 0x1FD80 which is important because space from 0x1FD80:0x1FFFF is used as the inter-processor communications block between the ZPU and the K64F I/O processor.

The output file would be <z-zOS>/main.bin which would be copied onto the SD card as /ZOS/ZOS.rom.

Build TZFS

Building the software and final load image can be done by cloning the repository and running some of the shell scripts and binaries provided.

TZFS is built as follows:

1. Make the TZFS binary using <tools>/assemble_tzfs.sh, this creates a ROM image <roms>/tzfs.rom which contains all the main and banked code.
2. Make the original MZ80A/MZ-700 monitor roms using <tools>/assemble_roms.sh, this creates <roms>/monitor_SA1510.rom, <roms>/monitor_80c_SA1510.rom, <roms>/monitor_1Z-013A.rom and <roms>/monitor_80c_1Z-013A.rom.
3. Copy and/or delete any required Sharp MZF files into/from the MZF directory.
4. Copy files to the SD card.

See below for the typical build stages.

Build CPM

To build CP/M please refer to the CP/M build section for additional information.

The CP/M version for the tranZPUter is slightly simpler to build as it doesnt involve preparing a special SD card or compacted ROM images.

The CP/M system is built in 4 parts,

1. the cpm22.bin which contains the CCP, BDOS and a CBIOS stub.
2. the banked CBIOS which has its primary source in a 4K page located at 0xF000:FFFF and a
   larger, upto 48K page, located in a seperate 64K RAM block.
3. the concatenation of 1 + 2 + MZF Header into an MZF format file which TZFS can load.
4. creation of the CPM disk drives which are stored as 16MB FAT32 files on the K64F SD card.

All of the above are encoded into 2 bash scripts, namely ‘assemble_cpm.sh’ and ‘make_cpmdisks.sh’ which can be executed as follows:

cd <software>
tools/assemble_cpm.sh
tools/make_cpmdisks.sh

The CPM disk images can be found in <cpm>/1M44/RAW for the raw images or <cpm>/1M44/DSK for the CPC Extended format disk images. These images are built from the directories in <cpm>, each directory starting with CPM* is packaged into one 1.44MB drive image. NB. In addition, the directories are also packaged into all the other supported disks as images in a corresponding directory, ie <cpm>/SDC16M for the 16MB SD Card drive image.

The CPM disks which exist as files on the SD Card are stored in <CPM>/SDC16M/RAW and have the format CPMDSK<number>.RAW, where <number> is 00, 01 … n and corresponds to the disk drive under CP/M to which they are attached (ie. standard boot, 00 = drive A, 01 = drive B etc. If the Floppy Disk Controller has priority then 00 = drive C, 01 = drive D). Under a typical run of CP/M upto 6 disks will be attached (the attachment is dynamic but limited to available memory).

A Typical Build

A quick start to building the software, creating the SD card and installing it has been summarized below.

# Obtain an SD Card and partition into 2 DOS FAT32 formatted partitions, mount them as <SD CARD P1> and <SD CARD P2>. The partition size should be at least 512Mb each.
# The first partition will host the software to run on the K64F I/O processor AND all the Sharp MZ software to be accessed by the Sharp MZ-700.
# The second partition will host the software to run on the ZPU Evo processor when it acts as the main Sharp MZ-700 processor.

# Build zOS (embedded)
cd <zsoft>
./build.sh -C K64F -O zos  -N 0x10000 -d -T
# Flash <z-zOS>/main.hex into the K64F processor via USB or OpenSDA.
cp -r build/SD/* <SD CARD P1>/

# Build zOS (user)
./build.sh -C EVO -O zos -o 0 -M 0x1FD80 -B 0x0000 -S 0x3D80 -N 0x4000 -A 0x100000 -a 0x80000 -n 0x0000 -s 0x0000 -d -Z
cp -r build/SD/* <SD CARD P2>/
# Ensure that the ZPU zOS kernel is copied to the K64F partition as it will be used for loading into the ZPU Evo on reset.
cp -rbuild/SD/ZOS/* <SD CARD P1>/ZOS/

# Build TZFS
cd <software>
tools/assemble_tzfs.sh
# Build the required host (Sharp) ROMS.
tools/assemble_roms.sh
# Build CPM
tools/assemble_cpm.sh
# Build the CPM disks.
tools/make_cpmdisks.sh

# Create the target directories on the SD card 1st partition and copy all the necessary applications and roms.
mkdir -p <SD CARD P1>/TZFS/
mkdir -p <SD CARD P1>/MZF/
mkdir -p <SD CARD P1>/CPM/
mkdir -p <SD CARD P1>/BAS
mkdir -p <SD CARD P1>/CAS
cp <software>/roms/tzfs.rom                   <SD CARD P1>/TZFS/
cp <software>/roms/monitor_SA1510.rom         <SD CARD P1>/TZFS/SA1510.rom
cp <software>/roms/monitor_80c_SA1510.rom     <SD CARD P1>/TZFS/SA1510-8.rom
cp <software>/roms/monitor_1Z-013A.rom        <SD CARD P1>/TZFS/1Z-013A.rom
cp <software>/roms/monitor_80c_1Z-013A.rom    <SD CARD P1>/TZFS/1Z-013A-8.rom
cp <software>/roms/monitor_1Z-013A-KM.rom     <SD CARD P1>/TZFS/1Z-013A-KM.rom
cp <software>/roms/monitor_80c_1Z-013A-KM.rom <SD CARD P1>/TZFS/1Z-013A-KM-8.rom
cp <software>/roms/MZ80B_IPL.rom              <SD CARD P1>/TZFS/MZ80B_IPL.rom
cp <software>/MZF/CPM223.MZF                  <SD CARD P1>/MZF/
cp <software>/roms/cpm22.bin                  <SD CARD P1>/CPM/
cp <software>/CPM/SDC16M/RAW/*                <SD CARD P1>/CPM/
cp <software>/MZF/*                           <SD CARD P1>/MZF/
cp <software>/BAS/*                           <SD CARD P1>/BAS/
cp <software>/CAS/*                           <SD CARD P1>/CAS/

# If you want TZFS to autostart, create an empty flag file as follows.
> <SD CARD P1>/TZFSBOOT.FLG

# If you want to run TZFS commands on each boot, create an autoexec.bat file and place required commands into the file.
> <SD CARD P1>/AUTOEXEC.BAT

# Eject the card and insert it into the SD Card reader on the tranZPUter board.
# Remove the Z80 from the Sharp MZ machine and install the tranZPUter board into the Z80 socket.
# Power on. If the autostart flag has been created, you should see the familiar monitor
# signon message followed by +TZFS. If the autostart flag hasnt been created, enter the command
# JE800 into the monitor to initialise TZFS.

To aid in building and preparing an SD card, I use a quick and dirty script <zSoft>/buildall which can be used but you would need to change the ROOT_DIR and disable the RSYNC (I use a remote computer to compile zOS and upload into the K64F).

Any errors and the script will abort with a suitable error message.

Flash K64F MPU

The original tranZPUter SW made use of the excellent Teensy development board from PJRC which was replaced in later tranZPUter SW releases by a 100pin TQFP version of the Freescale K64FX512 processor.

To use the Teensy Tool for programming, all the necessary files and executables can be found in the <z-tools> directory within the zSoft repository,

1. Connect the tranZPUter SW-700 board to your PC with the USB cable.
2. Launch the Teensy programming application: 
   <z-soft>/teensy 
3. In the Teensy application, select File->Open HEX file and navigate to the <z-zOS> or \z<zputa> directory (depending on which OS your uploading) and select the file 'main.hex'.
4. Press the 'K64F PROG' button on the tranZPUter SW-700 board.
5. In the Teensy application, select Operation->Program - this programs the onboard Flash RAM.
6. Ensure you have a terminal emulator open configured to the virtual serial device (if unsure, issue the 'dmesg' command from within Linux to see the latest USB attachment and its name). Normally the device is /dev/ttyACM0. There is no need to set the Baud rate or Bits/Parity, this is a virtual serial port and operates at USB speed.
7. In the Teensy application, select Operation->Reboot - this will now reboot the K64F and it will startup running zOS or ZPUTA.
8. Interact with the OS via the terminal emulator. 

For further information on the Teensy programming tool using U6 when installed, see the Teensy basic usage guide.

Bill Of Materials

The cost to make a tranZPUter SW-700 v1.3 Board can be seen in the table below. This excludes consumables such as solder paste and flux. Please scroll right to see the full table details.

Source: tranZPUter-SW-700_v1_3.sch
Component Count: 145

Credits

Where I have used or based any component on a 3rd parties design I have included the original authors copyright notice. All 3rd party software, to my knowledge and research, is open source and freely useable, if there is found to be any component with licensing restrictions, it will be removed from this repository and a suitable link/config provided.

Licenses

This design, hardware and software, is licensed under the GNU Public Licence v3.

The Gnu Public License v3