-This section provides internal design information for understanding how the tranZPUter SW-700 functions and its interactions with the Host (the original computer).
+This section provides internal design information for understanding how TZFS functions in the host (the original computer) and its interactions with the tranZPUter I/O processor.
-
-### K64F Z80 Host API
+###
The API is based on a common block of RAM within the 64K memory space of the Z80 through which interprocessor communications take place. On the K64F this is declared
@@ -326,7 +587,7 @@ in C as a structure and on the Z80 as an assembler reference to memory variables
```c
// 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,
+// Typically the z80 places a command into the structure in its 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.
@@ -372,15 +633,17 @@ typedef struct __attribute__((__packed__)) {
Communications are all instigated by the Z80. When it needs a service, it will write a command into the svcControl.cmd field and set the svcControl.result field to
REQUEST. The Z80 then writes to an output port (configurable but generally 0x68) which in turn sends an interrupt to the K64F. The K64F reads the command and sets the
-svcControl.result to PROCESSING - the Z80 waits for this handshake, if it doesnt see it after a timeout period it will resend the command. The Z80 then waits for a valid
-result, again if it doesnt get a result in a reasonable time period it retries the sequence and after a number of attempts gives up with an error.
+svcControl.result to PROCESSING - the Z80 waits for this handshake, if it doesn't see it after a timeout period it will resend the command. The Z80 then waits for a valid
+result, again if it doesn't get a result in a reasonable time period it retries the sequence and after a number of attempts gives up with an error.
Once the K64F has processed the command (ie. read directory) and stored any necessary data into the structure, it sets the svcControl.result to a valid result (success,
fail or error code) to complete the transaction.
-**API Command List**
+####
API Command List
+
+
| Command | Cmd# | Description |
| ------------------------- | -------- | ------------------------------------------------------------- |
@@ -402,7 +665,7 @@ fail or error code) to complete the transaction.
| TZSVC_CMD_LOAD80BIPL | 0x24 | Request the loading of the MZ-80B IPL, switch frequency and enable Sharp MZ-80B compatible mode. |
| TZSVC_CMD_LOAD800BIOS | 0x25 | Service command requesting that the MZ800 9Z-504M BIOS is loaded. |
| TZSVC_CMD_LOAD2000IPL | 0x26 | Service command requesting the MZ-2000 IPL is loaded. |
-| TZSVC_CMD_LOADTZFS | 0x2F | Service command requesting the loading of TZFS. This service is for machines which normally dont have a monitor BIOS. ie. MZ-80B/MZ-2000 and manually request TZFS. |
+| TZSVC_CMD_LOADTZFS | 0x2F | Service command requesting the loading of TZFS. This service is for machines which normally don't have a monitor BIOS. ie. MZ-80B/MZ-2000 and manually request TZFS. |
| TZSVC_CMD_LOADBDOS | 0x30 | Reload CPM BDOS+CCP. |
| TZSVC_CMD_ADDSDDRIVE | 0x31 | Attach a CPM disk to a drive number. |
| TZSVC_CMD_READSDDRIVE | 0x32 | Read an attached SD file as a CPM disk drive. |
@@ -426,7 +689,9 @@ fail or error code) to complete the transaction.
| TZSVC_CMD_SD_WRITESECTOR | 0x62 | Provide raw write access to the underlying SD card. |
| TZSVC_CMD_EXIT | 0x7F | Terminate TZFS and restart the machine in original mode. |
-**API Result List**
+####
API Result List
+
+
| Command | Result# | Description |
| ------------------------- | -------- | ------------------------------------------------------------- |
@@ -439,10 +704,10 @@ fail or error code) to complete the transaction.
--------------------------------------------------------------------------------------------------------
-### Z80 Memory Modes
+###
Z80 Memory Modes
-One of the features of the tranZPUter SW-700 hardware design is the ability to create memory maps freely within the 512 macro cell CPLD. Any conceivable memory map within Z80 address space (or any soft-cpu address space upto 18 bits wide)
+One of the features of the tranZPUter hardware design is the ability to create memory maps freely within the 512 macro cell CPLD. Any conceivable memory map within Z80 address space (or any soft-cpu address space up to 18 bits wide)
utilising the 512K Static RAM, 64K mainboard RAM, Video RAM, I/O can be constructed using a boolean equation and then assigned to a Memory Mode, The memory mode is then selected by Z80 software as required, ie. this ability is put to good
use in order to realise TZFS, CP/M and the compatible modes of the Sharp MZ-700 and MZ-80B.
@@ -470,7 +735,7 @@ Modes which have been defined are in the table below leaving a few available slo
| | | E000:E7FF | Main | MM I/O | | |
| | | E800:EFFF | RAM 0 | User ROM | | |
| | | F000:FFFF | Main | FDC ROM | | |
-| 2 | TZFS | 0000:0FFF | RAM 0 | MROM | No | Boot mode for TZFS or any other software requiring use of the tranZPUter RAM. User ROM appears as ROM to the Monitor so it will call the entry point at 0xE800 as part of it's normal startup procedure. The software stored at 0xE800 can switch out the mainboard and run in tranZPUter RAM as required. Two small holes at F3FE and F7FE exist for the Floppy disk controller (which have to be 2 bytes wude), these locations need to be on the mainboard. The floppy disk controller uses them as part of its data read/write as the Z80 isnt fast enough to poll the FDC. |
+| 2 | TZFS | 0000:0FFF | RAM 0 | MROM | No | Boot mode for TZFS or any other software requiring use of the tranZPUter RAM. User ROM appears as ROM to the Monitor so it will call the entry point at 0xE800 as part of its normal startup procedure. The software stored at 0xE800 can switch out the mainboard and run in tranZPUter RAM as required. Two small holes at F3FE and F7FE exist for the Floppy disk controller (which have to be 2 bytes wide), these locations need to be on the mainboard. The floppy disk controller uses them as part of its data read/write as the Z80 isn't fast enough to poll the FDC. |
| | | 1000:CFFF | RAM 0 | Main RAM | | |
| | | D000:D7FF | Main | VRAM | | |
| | | D800:DFFF | Main | ARAM | | |
@@ -571,7 +836,7 @@ Key:
-##### MZ700/MZ800 Memory Mode
+#####
MZ700/MZ800 Memory Mode
| MZ-700 ||||| | MZ-800 |
| Register |0000:0FFF|1000:1FFF|1000:CFFF|C000:CFFF|D000:FFFF |0000:7FFF|1000:1FFF|2000:7FFF|8000:BFFF|C000:CFFF|C000:DFFF|E000:FFFF |
@@ -595,43 +860,7 @@ Key:
---------------------------------------------------------------------------------------------------------
-
-### Z80 CPU Frequency Switching
-
-
-In order to make the tranZPUter SW-700 compatible with other machines it is necessary to clock the CPU at the speed of that machine. It is also desirable to clock the CPU as fast as possible when using software such
-as CP/M for maximum performance.
-
-
-One of the main issues with frequency switching is that the underlying host cannot have its frequency changed, the host is generally generating the clock and it's circuits have been designed to operate within it's clock
-tolerances. The tranZPUter SW-700 overcomes this limitation as described below.
-
-
-To fulfil the requirement to have a switchable Z80 CPU frequency a positive edge triggered frequency switch has been implemented which takes the host frequency as one input and a square wave generator from the K64F as its second input.
-The switching mechanism is tied to the bus control logic and so any access to the host will see the frequency of the CPU being changed to that of the host which ensures continued reliable operation. Under startup conditions, the Z80 is
-always clocked by the host clock to ensure original specifications of the machine are met.
-
-
-A second frequency can be selected if the K64F is present as it has the ability using its onboard timers to generate a programmable square wave output. The K64F sets the frequency of this second clock source
-and the Z80 can select it via an I/O OUT command. This gives the software running on the Z80 the opportunity to change it's own frequency, albeit to a fixed set one. An extension to the K64F Host API allows the Z80 to make a request
-of the K64F to set the Z80 CPU frequency to any possible value, this is useful in TZFS or CP/M so a user can select their own frequency.
-
-
-Current testing on a CMOS Z84C0020 20MHz CPU has the following observations:
-
-
- * 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.
-
-
-It is also possible to slow down the CPU for training or debugging purposes albeit access to the host circuitry will always run at the host clock frequency,
-
-
-On an application running under the Z80, the following table outlines the I/O ports to which it must read/write in order to switch frequencies.
-
-
-#####
Z80 CPU Frequency Switching Ports
+#####
Z80 CPU Frequency Switching Ports
| Port | Dir | Function |
| ---- | --- | -------- |
@@ -639,210 +868,20 @@ On an application running under the Z80, the following table outlines the I/O po
| 0x64 | W | Switch Z80 CPU frequency to default host source. This is the default on RESET. |
| 0x66 | R | Bit [0] - Clock Selected, 0 = Host Clock, 1 = second clock source (K64F or external oscillator). |
---------------------------------------------------------------------------------------------------------
-
-## 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 document. The repository can be found at [TZFS](https://github.com/pdsmart/TZFS).
-
-*tranZPUter Repository*
-
-| Short Name | Path | Description |
-|------------------|----------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------|
-| \
| \[\\]/tranZPUter/cpu | ZPU VHDL definition files. |
-| \ | \[\\]/tranZPUter/build | Build files for developing and tesing of the ZPU based tranZPUter board. |
-| \ | \[\\]/tranZPUter/devices | RTL definitions of hardware devices used in the ZPU development or tranZPUter development. |
-| \ | \[\\]/tranZPUter/docs | Any relevant documentation for the project. |
-| \ | \[\\]/tranZPUter/pcb | Gerber files, each tranZPUter version (SW, SW-700 and tranZPUter) within it's own sub-directory. |
-| \ | \[\\]/tranZPUter/schematics | Kicad schematics and PCB design files including component library definitions. |
-| \ | \[\\]/tranZPUter/software | Root directory for software used in the project. |
-| \ | \[\\]/tranZPUter/software/tools | Tools to aid in the compilation and creation of target files. |
-| \ | \[\\]/tranZPUter/software/asm | Z80 assembler files for TZFS, CP/M and various original monitor ROMS. |
-| \ | \[\\]/tranZPUter/software/roms | ROM files created by assembling the Z80 source. |
-| \ | \[\\]/tranZPUter/software/src/tools | tranZPUter v1 Flash RAM memory map decoder file creation tool and NASCOM Basic converter tool. |
-| \ | \[\\]/tranZPUter/software/CPM | Original CPM software, grouped according to application including generated Floppy Disk and SD Card images. |
-| \ | \[\\]/tranZPUter/software/MZF | Original Sharp MZF format applications which will be added into any generated SD Card image. |
-| \ | \[\\]/tranZPUter/software/BAS | A collection of converted NASCOM Basic programs in readable text format. These are added to generated SD Card images. |
-| \ | \[\\]/tranZPUter/software/CAS | A collection of NASCOM Basic tokenized tape programs converted from the NASCOM tape images. These are added to generated SD Card images. |
-| \ | \[\\]/tranZPUter/software/NASCAS | A collection of original NASCOM cassette images which havent been converted. Use the nasconv tool to convert. |
-| \ | \[\\]/tranZPUter/software/config | Configuration files for tools. Currently the disk definition description file for generation of CP/M images. |
-
-
---------------------------------------------------------------------------------------------------------
-
-### Tools
-
-
-All development has been made under Linux, specifically Debian/Ubuntu. I use Windows for the GUI version of CP/M Tools but havent dedicated any time into building TZFS under Windows. I will in due course
-create a Docker image with all necessary tools installed, but in the meantime, in order to assemble the Z80 code, the C programs and to work with the CP/M software and CP/M disk images, you will need to obtain and install the following tools.
-
-
-NB: For the K64F, the ARM compatible toolchain is currently stored in the repo within the build tree.
-
-| | |
-| --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
-[ZPU GCC ToolChain](https://github.com/zylin/zpugcc) | The GCC toolchain for ZPU development. Install into */opt* or similar common area. |
-[Arduino](https://www.arduino.cc/en/main/software) | The Arduino development environment, not really needed unless adding features to the K64F version of zOS from the extensive Arduino library. Not really needed, more for reference. |
-[Teensyduino](https://www.pjrc.com/teensy/td_download.html) | The Teensy3 Arduino extensions to work with the Teensy3.5 board at the Arduino level. Not really needed, more for reference. |
-[Z80 Glass Assembler](http://www.grauw.nl/blog/entry/740/) | A Z80 Assembler for converting Assembly files into machine code. I have had to fix a bug in the 0.5 release as it wouldnt create a byte at location 0xFFFF, this fixed version is stored in the \ directory in the repository. |
-[samdisk](https://simonowen.com/samdisk/) | A multi-os command line based low level disk manipulation tool. |
-[cpmtools](https://www.cpm8680.com/cpmtools/) | A multi-os command line CP/M disk manipulation tool. |
-[CPMToolsGUI](http://star.gmobb.jp/koji/cgi/wiki.cgi?page=CpmtoolsGUI) | A Windows based GUI CP/M disk manipulation tool. |
-[z88dk](https://www.z88dk.org/forum/) | An excellent C development kit for the Z80 CPU. |
-[sdcc](http://sdcc.sourceforge.net/) | Another excellent Small Device C compiler, the Z80 being one of its targets. z88dk provides an enhanced (for the Z80) version of this tool within its package. |
-
---------------------------------------------------------------------------------------------------------
-
-### Build TZFS
-
-Building the software and final load image can be done by cloning the [repository](https://github.com/pdsmart/tranZPUter.git) and running some of the shell scripts and binaries provided.
-
-TZFS is built as follows:
-
- 1. Make the TZFS binary using \/assemble_tzfs.sh, this creates a ROM image \/tzfs.rom which contains all the main and banked code.
- 2. Make the original MZ80A/MZ-700 monitor roms using \/assemble_roms.sh, this creates \/monitor_SA1510.rom, \/monitor_80c_SA1510.rom, \/monitor_1Z-013A.rom and \/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](/sharpmz-upgrades-tranzputer-sw/#a-typical-build) for the typical build stages.
-
-
---------------------------------------------------------------------------------------------------------
-
-### Build CPM
-
-To build CP/M please refer to the [CP/M build section](/sharpmz-upgrades-cpm/#building-cpm) 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:
-
-```bash
-cd
-tools/assemble_cpm.sh
-tools/make_cpmdisks.sh
-```
-
-The CPM disk images can be found in \/1M44/RAW for the raw images or \/1M44/DSK for the CPC Extended format disk images. These images are built from the directories in
- \, 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 \/SDC16M for the 16MB SD Card drive image.
-
-The CPM disks which exist as files on the SD Card are stored in \/SDC16M/RAW and have the format CPMDSK\.RAW, where \ 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.
-
-````bash
-# Obtain an SD Card and partition into 2 DOS FAT32 formatted partitions, mount them as and . 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
-./build.sh -C K64F -O zos -N 0x10000 -d -T
-# Flash /main.hex into the K64F processor via USB or OpenSDA.
-cp -r build/SD/* /
-
-# 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/* /
-# 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/* /ZOS/
-
-# Build TZFS
-cd
-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 /TZFS/
-mkdir -p /MZF/
-mkdir -p /CPM/
-mkdir -p /BAS
-mkdir -p /CAS
-cp /roms/tzfs.rom /TZFS/
-cp /roms/monitor_SA1510.rom /TZFS/SA1510.rom
-cp /roms/monitor_80c_SA1510.rom /TZFS/SA1510-8.rom
-cp /roms/monitor_1Z-013A.rom /TZFS/1Z-013A.rom
-cp /roms/monitor_80c_1Z-013A.rom /TZFS/1Z-013A-8.rom
-cp /roms/monitor_1Z-013A-KM.rom /TZFS/1Z-013A-KM.rom
-cp /roms/monitor_80c_1Z-013A-KM.rom /TZFS/1Z-013A-KM-8.rom
-cp