tranZPUter SW

Foreword

Overview

tranZPUter SW

Hardware

v1.0 Z80 Upgrade Schematic

v1.0 Teensy 3.5 Schematic

v1.0 PCB

v1.1 Z80 Upgrade Schematic

v1.1 Teensy 3.5 Schematic

v1.1 PCB

v2.0 Z80 Upgrade Schematic

v2.0 Teensy 3.5 Schematic

Version 2.0 is very similar to v1.1, just adding additional connectivity as the list of ideas grow.

v2.0 PCB

v2.1 Z80 Upgrade Schematic

v2.1 Teensy 3.5 Schematic

v2.1 PCB

v2.2 Z80 Upgrade Schematic

v2.2 The K64 I/O Processor

v2.2 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.
    };
    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

API Result List

GPIO Organisation

K64F Port and Bit allocation

GPIO bits to Z80 Address Line mapping

GPIO bits to Z80 Data Line mapping

Memory Modes

MZ700/MZ800 Memory Mode

Z80 CPU Frequency Switching

• tranZPUTer reliable in the range 1Hz to 20MHz for all functionality.
• tranZPUter reliable @ 24MHz on the tranZPUter v2.1 board. When the mainboard is accessed the frequency slows to 2MHz (or the system clock) and returns to the higher frequency after the mainboard access has completed. Under development is the MZ80A Video Module which controls the mainboard frequency, so it should be feasible to clock the mainboard at 4+MHz shortly. I overclocked my original Sharp MZ80A to 4MHz, thus from previous experience and analysing the mainboard components inside the Sharp MZ80A, it should be feasible to overclock.

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)

Sharp MZ-700 Mode

tranZPUter v1.1

The MZ80A COLOUR BOARD v1.0 solves the display incompatibility with one small caveat. When I designed the colour board I opted to follow the original Sharp MZ80A colour upgrad attribute mapping even though this board was never commercially sold. This makes slight incompatibilities with an MZ-700 in colour choice but in general works well. A few minutes with a soldering iron can correct this if needed. The colour board also provides the MZ-700 character generator maps so all characters seen on an MZ-700 can be displayed on the MZ-80A.

tranZPUter v2.1

Keyboard Mapping

Mapping has been made by copying the MZ-700 keyboard layout onto the MZ-80A.

All other keys are the same between the machines.

Sharp MZ-80B Mode

Studying the MZ-80B it is my intention to intercept IO transactions and convert them into memory mapped transactions with the help of the wait state generator. Memory, as per the MZ-700 will be accomodated by memory mappings in the 512K Flash RAM decoder. The Character based Video is common amongst all machines at 0xD000 so it should be possible to run most MZ-80B software on the MZ-80A/MZ-700. Graphics will be possible with the upcoming update of the MZ80A COLOUR BOARD but little steps first, get the IPL to boot and load cassette basic…

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-80A and the tranZPUter Z80 upgrade logic. It’s purpose is to provide

• Z80 Memory Map decoding
• Z80 BUS control
• WAIT State generation
• Hardware remapping
• Voltage translation

The source files which form the CPLD configuration are:

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/SW/build/tranZPUterSW.qpf, this will open the CPLD tranZPUterSW 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: tranZPUterSW.sof in the <Clone Path>/tranZPUter/CPLD/SW/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 tranZPUterSW 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 1 device, an EPM7512AET144.
   5. Right click on the EPM7512AET144 device, select Add File then choose the sof file located in <Clone Path>/tranZPUter/CPLD/SW/build/output_files/tranZPUterSW.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.

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

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'

If the 40/80 column card is installed, typing ‘4’ switches to 40 Column display, typing ‘8’ switches to 80 Column display. For the directory listing commands, 4 columns of output will be shown when in 80 column mode.

Sharp BASIC SA-5510

To LOAD or SAVE to the builtin cassette drive, use the commands:
    CDC
    LOAD
or
    CDC
    SAVE “EXAMPLE”

The new version of BASIC SA-5510 is named “BASIC SA-5510-TZ”. </div>

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.

Memory Decoder Tool

The early tranZPUter SW designs ( < v2.0) used a 512KB Flash RAM as the active decoder. This was chosen intentionally to allow multiple different memory maps so as the development progressed the tranZPUter SW could run software from the MZ80K/C/B/700/800 machines as they all are similar just with different memory maps (graphics can differ but the MZ80A Colour Board does a pretty good job at providing compatible video for an MZ-700 and with the advent of the Video Module v2.0 it will enable MZ80B/800 capable pixel graphics as well.

In order to generate the decoder bit map I have written a tool in C which creates the map based on Z80 signal logic. The logic uses Z80 signals so it is relatively straight forward to say ‘Memory map 5, Z80 WR and Addr:0xE800:EFFF has tranZPUter RAM mapped into it’.

An example of creating a decoder map using signals within the C program:

    // Pre transaction setup. The address lines contain the next address prior to the RD/WR/MREQ/IORQ signals being asserted. If a set
    // uses mixed resources, ie tranZPUter ond mainboard then their is a propogation delay from the FlashRAM being presented with the signals
    // to it outputting a signal plus additional delays for the 279 SR latch, 74HCT08 AND gate and the tristate buffers on the mainboard. This
    // action on the address to pre enable the mainboard or tranZPUter removes the propagation effect on the BUSACK signal on the main board.
    //
    switch(set)
    {
        // Set 3 - Monitor ROM 0000-0FFF, Main RAM area 0x1000-0xD000, User ROM 0xE800-EFFF are in tranZPUter memory block 0, Floppy ROM F000-FFFF are in tranZPUter memory block 1.
        // NB: Main DRAM will not be refreshed so cannot be used to store data in this mode.
        case 3:
            if( (Z80_ADDR >= 0x0000 && Z80_ADDR < 0xD000) || (Z80_ADDR >= 0xE800 && Z80_ADDR < 0xF000)) 
            {
                flashRAM[set].tranche[inSignals].DISABLE_BUS = 0;
                flashRAM[set].tranche[inSignals].ENABLE_BUS = 1;
            } else if ((Z80_ADDR >= 0xF000 && Z80_ADDR < 0xF3C0) || (Z80_ADDR >= 0xF400 && Z80_ADDR < 0xF7C0) || (Z80_ADDR >= 0xF800 && Z80_ADDR < 0x10000))
            {
                flashRAM[set].tranche[inSignals].DISABLE_BUS = 0;
                flashRAM[set].tranche[inSignals].ENABLE_BUS = 1;
                flashRAM[set].tranche[inSignals].A16 = 1;
                flashRAM[set].tranche[inSignals].A17 = 0;
                flashRAM[set].tranche[inSignals].A18 = 0;
            } else
            {
                flashRAM[set].tranche[inSignals].DISABLE_BUS = 1;
                flashRAM[set].tranche[inSignals].ENABLE_BUS = 0;
            } 
            break;

            ...

    // Specific mapping for Memory Writes.
    if(Z80_MEM_WRITE)
    {
        switch(set)
        {
            // Set 3 - Monitor ROM 0000-0FFF, Main RAM area 0x1000-0xD000, User ROM 0xE800-EFFF are in tranZPUter memory block 0, Floppy ROM F000-FFFF are in tranZPUter memory block 1.
            // NB: Main DRAM will not be refreshed so cannot be used to store data in this mode.
            case 3:
                if( (Z80_ADDR >= 0x0000 && Z80_ADDR < 0xD000) || (Z80_ADDR >= 0xE840 && Z80_ADDR < 0xF3C0) || (Z80_ADDR >= 0xF400 && Z80_ADDR < 0xF7C0) || (Z80_ADDR >= 0xF800 && Z80_ADDR < 0x10000)) 
                {
                    flashRAM[set].tranche[inSignals].DISABLE_BUS = 0;
                    flashRAM[set].tranche[inSignals].RAM_WE = 0;
                    flashRAM[set].tranche[inSignals].RAM_OE = 1;
                }
                break;

              ...

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

FLASHMMCFG v1.0

Options:-
  -h | --help              This help test.
  -i | --io-addr <addr>    Base address for the IO Control Registers.
  -o | --output <file>     Output the final binary image to the given file. This file is programmed into the Flash RAM.
  -v | --verbose           Output more messages.

Examples:
  flashmmcfg --output Decode1.bin --io-addr 0x20       Create the mapping binary using 0x20 as the base address for the IO Control Registers.

Building tranZPUter SW Software

The tranZPUter SW board requires several software components to function:

• zOS - the integral operating system running on the K64F I/O processor
• TZFS - the Z80 based operating or filing system running on the Sharp MZ80A
• Memory decoder - the 512Kbyte map which forms the hardware decoder logic of the tranZPUter board
• CP/M - A real operating system for Microcomputers which I ported to the Sharp MZ80A 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

For the Teensy3.5/K64F the ARM compatible toolchain is currently stored in the repo within the build tree.

Build zOS

To build zOS please refer to the zOS build section.

A typical buid 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 Teensy 3.5 board.

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 monitor roms using <tools>/assemble_roms.sh, this creates <roms>/monitor_SA1510.rom and <roms>/monitor_80c_SA1510.rom.
3. Copy and/or delete any required Sharp MZF files into the MZF directory.
4. Copy files to the SD card.

See below for the typical build stages.

Build the Memory Decoder

To build the memory decoder map for flashing into a 512K Fash RAM clone the repository and follow the steps below:

1. Change to directory and issue command: make make install
2. Run the command: /flashmmcfg --output /tranZPUterDecoderMappingFile.bin
3. Flash the file:/tranZPUterDecoderMappingFile.bin to a suitable 512KB Flash RAM.

Adding decoding logic is a matter of editting the file <software>/src/tools/flashmmcfg.c and adding suitable clauses in the setMap() method.

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.

# Build zOS
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>/

# 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 and copy all the necessary applications and roms.
mkdir -p <SD CARD>/TZFS/
mkdir -p <SD CARD>/MZF/
mkdir -p <SD CARD>/CPM/
mkdir -p <SD CARD>/BAS
mkdir -p <SD CARD>/CAS
cp <software>/roms/tzfs.rom                   <SD CARD>/TZFS/
cp <software>/roms/monitor_SA1510.rom         <SD CARD>/TZFS/SA1510.rom
cp <software>/roms/monitor_80c_SA1510.rom     <SD CARD>/TZFS/SA1510-8.rom
cp <software>/roms/monitor_1Z-013A.rom        <SD CARD>/TZFS/1Z-013A.rom
cp <software>/roms/monitor_80c_1Z-013A.rom    <SD CARD>/TZFS/1Z-013A-8.rom
cp <software>/roms/monitor_1Z-013A-KM.rom     <SD CARD>/TZFS/1Z-013A-KM.rom
cp <software>/roms/monitor_80c_1Z-013A-KM.rom <SD CARD>/TZFS/1Z-013A-KM-8.rom
cp <software>/roms/MZ80B_IPL.rom              <SD CARD>/TZFS/MZ80B_IPL.rom
cp <software>/MZF/CPM223.MZF                  <SD CARD>/MZF/
cp <software>/roms/cpm22.bin                  <SD CARD>/CPM/
cp <software>/CPM/SDC16M/RAW/*                <SD CARD>/CPM/
cp <software>/MZF/*                           <SD CARD>/MZF/
cp <software>/BAS/*                           <SD CARD>/BAS/
cp <software>/CAS/*                           <SD CARD>/CAS/

# If you want TZFS to autostart, create an empty flag file as follows.
> <SD CARD>/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>/AUTOEXEC.BAT

# Eject the card and insert it into the Teensy3.5 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.

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. 

Flash Teensy3.5

For earlier versions of the tranZPUter SW which use a Teensy 3.5 development board, you need to flash the program via its USB connector.

All the necessary files and executables to program the Teensy can be found in the <z-tools> directory within the zSoft repository,

To program the Teensy after an OS build, follow the steps below:

1. Connect the teensy 3.5 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 RESET button on the Teensy 3.5
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, see the Teensy basic usage guide.

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