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

Updated README

Browse Source
This commit is contained in:
Philip Smart
2020-03-24 16:28:24 +00:00
parent a43d28dec9
commit 894fa40c2b
2 changed files with 829 additions and 123 deletions
Download Patch File Download Diff File Expand all files Collapse all files

358
README.md
View File

@@ -1,123 +1,337 @@
Please consult my [GitHub](https://pdsmart.github.io) website for more upto date information.
## Overview ## Overview
The Sharp MZ80A as with most vintage computers had limited storage. In order to expand the hardware it is often the case that the resident software has to be enhanced which was impossible given the storage space (ie. 4K Monitor rom). The Sharp MZ80A has a 4K Monitor ROM, a 2K User ROM/RAM and space within the memory map to add a further 4K ROM typically for the floppy disk drive. The Sharp MZ80A as with most vintage computers had limited storage. In order to expand the storage it is often the case that the resident software has to be enhanced which was impossible
given the storage space (ie. 4K Monitor rom). The Sharp MZ80A has a 4K Monitor ROM, a 2K User ROM/RAM and space within the memory map to add a further 4K ROM typically for the floppy disk
drive.
One of the seperate projects I've been working on was a 40/80 Column switchable display and colour output. This upgrade requires different software, either a complete rewrite of the original monitor or a patched copy for 80 column mode. Wanting to keep the machine as original as possible, using a rewritten ROM is out of the question thus I would need 2 ROMS, original for 40Column and a patched one for 80Column. One of the seperate projects I've been working on was a 40/80 Column switchable display and colour output. This upgrade requires different software, either a complete rewrite of the original
monitor or a patched copy for 80 column mode. Wanting to keep the machine as original as possible, using a rewritten ROM is out of the question thus I would need 2 ROMS, original for 40Column
and a patched one for 80Column.
Thus was born the need for Rom Paging, ie. Use a modern Flash ROM to house multiple 4K Roms which can be switched in according to the hardware upgrade. Thus was born the need for Rom Paging, ie. Use a modern Flash RAM to house multiple 4K Roms which can be *switched in* according to the hardware upgrade.
It was also seen that using large Flash ROMS it was possible to store programs that would normally be present on tape or floppy and load at much higher speed making use of the computer that much easier. It was also seen when using large Flash RAM's it was possible to store programs that would normally be present on tape or floppy and load at much higher speed making use of the computer that
much easier.
This upgrade uses the 4K Monitor ROM and 2K User ROM space to map in 2x512Kbyte Flash ROMS providing paged roms and a Rom Filing System storing most commonly used programs. This upgrade uses the 4K Monitor ROM and 2K User ROM space to map in 2x512Kbyte Flash RAM's providing paged roms and a Rom Filing System storing most commonly used programs.
I havent yet documented this upgrade as it is still undergoing minor tweaks, but within this repository are the schematics, PCB Gerber files and the software to implement the Rom Filing System. This page along with the [CP/M](/sharpmz-upgrades-cpm) page forms the start of the RFS documentation which is still in its infancy. Within this repository are the schematics, PCB Gerber files and the software to implement the Rom Filing
System hardware and software.
## Rom Filing System v1.0 ## Rom Filing System
The Rom Filing System replaces the Monitor ROM and User ROM by lifter sockets onto a daughter card where 2x512Kbyte Flash RAM's are sited. One Flash RAM is paged into the Monitor ROM socket and the other into the User ROM socket. The first 16Kbyte of each Flash RAM is dedicated to paged ROMs with the remainder being used to store Sharp MZF format binary images compacted within 256byte sectors.
The necessary software to alow bank paging and the Rom Filing System additions has been written and can be found in software/asm, the following table describes each file. The Rom Filing System is a hardware and software upgrade for the Sharp MZ80A. The hardware replaces the Monitor ROM and User ROM's on the motherboard by a daughter card with lifer sockets where 2x512Kbyte Flash RAM's are sited.
One of the Flash RAM's is paged into the Monitor ROM socket and the other into the User ROM's socket. The first 32Kbytes (8 slots x 4K) of the Monitor Flash RAM and the first 24Kybtes (12 slots of 2K) of the User Flash RAM is
dedicated to paged ROMs with the remainder being used to store Sharp MZF format binary images compacted within 256byte sectors. (*NB. This may change to 128 byte sectors as the original reason for choosing 256 byte
sectors no longer exists*).
### RFS Hardware
![image](../images/MZ80A_RFS_v1_1.png)
It is quite easy to make upgrades for older tech these days by using one of the plethora of microcontrollers such as the Raspberry Pi. I did consider using one as a ROM emulator but then the goal of this project and the other
Sharp MZ80A upgrades, excepting the Transzputer, was to use old tech and keep the machine original. Thus the hardware uses 74 series components and Flash RAMS.
The basic circuit above employs address decoding, creating a select line at 0xEFFD-0xEFFF, latches to hold the upper address lines of the Flash RAM and the Flash RAM's themselves. Quite basic in fact.
The next version will be slightly more advanced as it will contain a coded latch (pattern buffer) to enable latch selection within the same address space as the Flash RAM, which will free up the address space to allow writing
into the Flash RAM from the MZ80A. Given the MZ80A design, tri-state buffers are needed on the Monitor ROM as this is read only. It will also include an SD Card controller, currently the design uses bitbanging but I have a more complex
shift register experiment on patch board, it uses more logic ic's but will afford greateer performance. Bigbanging works but on a Z80, the speed is comparable with a floppy disk drive rather than a hard drive or ROM drive.
### RFS Software
In order to use the RFS Hardware, a comprehensive set of Z80 assembler methods needed to be written to allow bank paging and with it came the option, which was taken, to upgrade the machines monitor functionality. This Z80
software forms the Rom Filing System which can be found in the repository within the \<software\> directory.
The following table describes each major file which forms the Rom Filing System:
| Module | Target ROM | Size | Bank | Description | | Module | Target ROM | Size | Bank | Description |
|------------------------|------------|------|------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------| |------------------------|------------|------|------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| rfs.asm | User | 2K | 0 | Primary Rom Filing System and MZ700/MZ800 Monitor tools. | | rfs.asm | User | 2K | 0 | Primary Rom Filing System and MZ700/MZ800 Monitor tools. |
| rfs_bank1.asm | User | 2K | 1 | Empty - further functionality can be placed here. | | rfs_bank1.asm | User | 2K | 1 | Floppy disk controller functions. |
| rfs_bank2.asm | User | 2K | 2 | Empty - further functionality can be placed here. | | rfs_bank2.asm | User | 2K | 2 | SD Card controller functions. |
| rfs_bank3.asm | User | 2K | 3 | Memory Test utility and 8253 Timer test. | | rfs_bank3.asm | User | 2K | 3 | Memory monitor utilities and help screen functions. |
| rfs_bank4.asm | User | 2K | 4 | Empty - further functionality can be placed here. | | rfs_bank4.asm | User | 2K | 4 | CMT functions. |
| rfs_bank5.asm | User | 2K | 5 | Empty - further functionality can be placed here. | | rfs_bank5.asm | User | 2K | 5 | Unused. |
| rfs_bank6.asm | User | 2K | 6 | Empty - further functionality can be placed here. | | rfs_bank6.asm | User | 2K | 6 | Unused. |
| rfs_bank7.asm | User | 2K | 7 | Empty - further functionality can be placed here. | | rfs_bank7.asm | User | 2K | 7 | Memory Test utility and 8253 Timer test. |
| cbios_bank1.asm | User | 2K | 8 | CPM CBIOS Utilities and Audio functions. |
| cbios_bank2.asm | User | 2K | 9 | CPM CBIOS Screen and ANSI Terminal functions. |
| cbios_bank3.asm | User | 2K | 10 | CPM CBIOS SD Card Controller functions. |
| cbios_bank4.asm | User | 2K | 11 | CPM CBIOS Floppy Disk Controller functions. |
| monitor_SA1510.asm | Monitor | 4K | 0 | Original SA1510 Monitor for 40 character display. | | monitor_SA1510.asm | Monitor | 4K | 0 | Original SA1510 Monitor for 40 character display. |
| monitor_80c_SA1510.asm | Monitor | 4K | 1 | Original SA1510 Monitor patched for 80 character display. | | monitor_80c_SA1510.asm | Monitor | 4K | 1 | Original SA1510 Monitor patched for 80 character display. |
| rfs_mrom.asm | Monitor | 4K | 2 | Rom Filing System helper functions located in the Monitor ROM space in Bank 3. These functions are used to scan and process MZF files stored within the User ROM space. | | cbios.asm | Monitor | 4K | 2 | CPM CBIOS (exec location 0xC000:0xCFFFF). |
| unused | Monitor | 4K | 3 | Unused slot for further functionality. | | rfs_mrom.asm | Monitor | 4K | 3 | Rom Filing System helper functions located in the Monitor ROM space in Bank 3. These functions are used to scan and process MZF files stored within the User ROM space. |
| unassigned | Monitor | 4K | 4 | Unused slot. |
| unassigned | Monitor | 4K | 5 | Unused slot. |
| unassigned | Monitor | 4K | 6 | Unused slot. |
| unassigned | Monitor | 4K | 7 | Unused slot. |
rfs.asm and all the rfs_bank< x >.asm are for the User ROM software which is invoked by the original Monitor ROM on startup. The functionality in these files provides the RFS file system and additional MZ700/800 style utilities. The way the code is structured, a call can be made from one bank to another without issue (stack and execution point manipulation is taken care of) thus providing almost 16K program space in the User ROM slot.
rfs_mrom.asm is located in the 3rd bank (bank 2) of the Monitor ROM (bank 0 = original SA1510 ROM, bank 1 = 80 column modified SA1510 ROM) and provides utilities needed by the Rom Filing System. These utilities are specifically needed for scanning and loading MZF files stored in the User ROM Flash RAM (because code executing in the User ROM cant page itself out to scan the remainder of the ROM). In the User ROM, the rfs.asm module and all the rfs_bank\<x\>.asm modules form the Rom Filing System and are invoked by the original SA-1510 monitor on startup of the MZ80A (or reset). The functionality in these files provides
the Rom Filing System and additional MZ700/800 style monitor utilities. The way the code is structured, a call can be made from one bank to another without issue (stack and execution point manipulation is taken care of) thus
providing almost 16K program space in the User ROM slot.
The two shell scripts software/proc_mzf.sh and software/make_roms.sh are simple shell scripts used to convert MZF files into a ROM images. proc_mzf.sh takes a set of MZF files and pads them to the desired sector size, ie. 256 bytes. make_roms.sh is a manually coded shell script to enable copying of required software and MZF files into a ROM image suitable for flashing into the Flash RAM's Sharing the User ROM banks are the cbios_bank\<x\>.asm modules which form part of the CP/M Custom BIOS. They extend the functionality of the CBIOS without impacting RAM usage which is crucial within CP/M in order
to run as many applications as possible.
To build the software, there is a shell script in the tools directory called assemble_rfs.sh. This script requires the GLASS Z80 Assembler which is freely downloadable (https://bitbucket.org/grauw/glass/src/default/). In the Monitor ROM, the rfs_mrom.asm module is located within the 4th bank (bank 3, bank 0 = original SA1510 ROM, bank 1 = 80 column modified SA1510 ROM) and provides utilities needed by the Rom Filing
System. These utilities are specifically needed for scanning and loading MZF files stored in the User ROM Flash RAM (because code executing in the User ROM cant page itself out to scan the
remainder of the ROM).
CPM v2.2 has been added with the CBIOS (Custom BIOS) being implemented within an MROM Bank (bank 2) along with User ROM Banks 8-11 mentioned above. This saves valuable RAM leaving only the CPM CCP and BDOS in RAM which can
be overwritten by programs, this gives a feasible 47K of useable program RAM. An intention is to include a paged RAM chip in the next release of the RFS Hardware which will allow upto 52K of program RAM.
There are several rapidly written shell scripts to aid in the building of the RFS software (which in all honesty need to be written into a single Python or Java tool). These can be seen in the following table along with their purpose:
| Script | Description |
|------------------ | ------------------------------------------------------------------------------------------------------------------------ |
| assemble_cpm.sh | A shell script to build the CPM binary, the CPM MZF format application for loading via RFS and the CPM ROM Drives 0 & 1 |
| assemble_rfs.sh | A bash script to build the Rom Filing System ROM images. |
| assemble_roms.sh | A bash script to build all the standard MZ80A ROMS, such as the SA-1510 monitor ROM. |
| make_roms.sh | A bash script to build the RFS ROMS suitable for programming in the 512KByte Flash RAMS. These images contain the banked RFS ROMS, the various system ROMS such as SA-1510 and all the MZF programs to be loaded by the RFS. |
| make_cpmdisks.sh | A bash script to build a set of CPM disks, for use as Raw images in the SD Card or Rom drives and as CPC Extended Disk Formats for use in a Floppy disk emulator or copying to physical medium. |
| make_sdcard.sh | A bash script to create an SD card image combining the RFS Image and several CPM disk drives. This image is then binary copied onto the SD card and installed into the RFS SD Card reader. |
| mzftool.pl | A perl script to create/extract and manipulate MZF images. |
| processMZFfiles.sh| A bash script to convert a set of MZF programs into sectored images suitable for use in the Rom Filing System ROMS. |
| sdtool | A binary created from the src/tools repository which builds the RFS SD Card image, creating a directory and adding MZF/Binary applications into the drive image. |
To build the software, the assemble_\<name\> shell scripts are used. These scripts requires the [GLASS Z80 Assembler](https://bitbucket.org/grauw/glass/src/default/) which is freely downloadable.
The procedure to build a ROM is:-<br/> The procedure to build a ROM is:-<br/>
1. Take a set of MZF files and convert them into correct sector padded binary files. The proc_mzf.sh file takes a directory and processes all files within it, transforming originalfile.mzf to originalfile.mzf.<sector size>.bin<br/> 1. Take a set of MZF files and convert them into correct sector padded binary files. The proc_mzf.sh file takes a directory and processes all files within it, transforming originalfile.mzf to originalfile.mzf.\<sector size>.bin<br/>
2. Build the Z80 code using software/tools/assemble_rfs.sh (or software/tools/assemble_roms.sh for compiling all source including the SA1510 monitor ROM).<br/> 2. Build the Z80 code using \<tools\>/assemble_rfs.sh for the RFS components, \<tools\>/assemble_roms.sh for assembling all original ROM source including the SA1510 monitor ROM, \<tools\>/assemble_cpm.sh for
3. Build the ROM using the software/make_roms.sh - before using you need to create your own section of MZF files by listing the files with ls -l then converting them into a set of ROM256_USER variables for programs that will go into the User Socket Flash RAM and ROM256_MROM variables for programs that will go into the Monitor Socket Flash RAM.<br/> assembling the CPM binaries and dependencies.<br/>
3. Build the ROM using the \<tools\>/make_roms.sh script - before using this you need to create your own selection of MZF files by listing the files with ls -l then converting them into a set of ROM_INCLUDE variables for programs that
will go into the User and Monitor Flash RAM's.<br/>
Upon boot, the typical SA1510 signon banner will be appended with "+ RFS" if all works well. You can then issue MZ700/MZ800 monitor commands or I to list Rom Filing System contents. To Load a program from the Rom Filing System, type:-<br/> ### RFS Monitor
L\<RFS number - as seen in the I command output ><br/>
or<br/>
L\<program name ><br/>
(Using lower case 'l' in place of 'L' doesnt auto execute the program once loaded into memory)
If the 40/80 column card is installed, typing '4' switches to 40 Column display, typing '8' switches to 80 Column display. Upon boot, the typical SA1510 signon banner will appear and be appended with "+ RFS" if all works well. The usual '\* ' prompt appears and you can then issue any of the original SA-1519 commands along with an enhanced set
some of which original from the MZ700/MZ800 and others are custom. The full set of commands are listed in the table below:
The supported commands can be found in the table below:
| Command | Parameters | Description | | Command | Parameters | Description |
|---------|-------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| |---------|-------------------------------------|------------------------------------------------------------------------------------|
| 4 | n/a | Switch to 40 Character mode if the 40/80 Column display upgrade has been added\. | | 4 | n/a | Switch to 40 Character mode if the 40/80 Column display upgrade has been added\. |
| 8 | n/a | Switch to 80 Character mode if the 40/80 Column display upgrade has been added\. | | 8 | n/a | Switch to 80 Character mode if the 40/80 Column display upgrade has been added\. |
| B | n/a | Enable/Disable key entry beep\. | | B | n/a | Enable/Disable key entry beep\. |
| C | n/a | Initialise memory from 0x1200 \- Top of RAM\. | | C | n/a | Initialise memory from 0x1200 \- Top of RAM\. |
| D | \<address> | List/Dump memory from \<address> in hex and ascii\. | | D | \<address>\[\<address2>\] | List/Dump memory from \<address> for in hex and ascii for 80 bytes or upto \<address2\>\. |
| F | n/a | Boot from Floppy Disk | | F | n/a | Boot from Floppy Disk |
| I | n/a | List the files stored in ROM\. Each file title is preceded with a hex number which can be used to identify the file\. | | f | n/a | Execute the original Floppy Disk AFI code @ 0xF000 |
| H | n/a | Help screen of all these commands\. |
| IR | n/a | Paged directory listing of the files stored in ROM\. Each file title is preceded with a hex number which can be used to identify the file\. |
| IC | n/a/ | Paged directory listing of the files stored on the SD Card\. Each file title is preceded with a hex number which can be used to identify the file\. |
| J | \<address> | Jump \(start execution\) at location \<address>\. | | J | \<address> | Jump \(start execution\) at location \<address>\. |
| L | \<name> or \<file number> | Load file into memory from Tape or Rom Filing System\. If a \<name> or \<file number> is given, the RFS is searched, if no parameter is given then the first program encountered on tape will be loaded\. | | L \| LT | n/a | Load file into memory from Tape and execute\. |
| l | \<name> or \<file number> | Same as above but once the program is loaded it will not be executed\. Control will return to the monitor\. | | LTNX | n/a | Load file into memory from Tape, dont execute\. |
| LR | \<name> or \<file number> | Load file into memory from ROM\. The ROM is searched for a file with \<name> or \<file number> and if found, loaded and executed\. |
| LRNX | \<name> or \<file number> | Load file into memory from ROM\. The ROM is searched for a file with \<name> or \<file number> and if found, loaded and not executed\. |
| LC | \<name> or \<file number> | Load file into memory from SD Card\. The SD Card is searched for a file with \<name> or \<file number> and if found, loaded and executed\. |
| LCNX | \<name> or \<file number> | Load file into memory from SD Card\. The SD Card is searched for a file with \<name> or \<file number> and if found, loaded and not executed\. |
| M | \<address> | Edit and change memory locations starting at \<address>\. | | M | \<address> | Edit and change memory locations starting at \<address>\. |
| P | n/a | Run a connected printer test\. | | P | n/a | Run a connected printer test\. |
| R | n/a | Run a memory test on the main memory\. | | R | n/a | Run a memory test on the main memory\. |
| S | \<start addr> \<end addr> \<exec addr> | Save a block of memory to tape\. You will be prompted to enter the filename\. | | S | \<start addr> \<end addr> \<exec addr> | Save a block of memory to tape\. You will be prompted to enter the filename\. |
| SC | \<start addr> \<end addr> \<exec addr> | Save a block of memory to SD Card\. You will be prompted to enter the filename\. |
| T | n/a | Test the 8253 timer\. | | T | n/a | Test the 8253 timer\. |
| V | n/a | Verify a file just written to tape with the original data stored in memory | | V | n/a | Verify a file just written to tape with the original data stored in memory |
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.
## Building RFS
Building the Rom Filing System involves assembling the Z80 Assembly language source into a machine code binary and packaging it into an image suitable for writing onto a 512Kbyte Flash RAM. You may also want to include MZF applications
in the ROMS for rapid exection via the RFS system. If you intend to use CPM, see also the CPM documentation.
To accomplish it you need several tools and at the moment it is quite a manual process.
## Paths
For ease of reading, the following shortnames refer to the corresponding path in this chapter.
| Short Name | |
|------------------|----------------------------------------------------------------------------|
| \[\<ABS PATH>\] | The path where this repository was extracted on your system. |
| \<software\> | \[\<ABS PATH>\]/MZ80A_RFS/software |
| \<roms\> | \[\<ABS PATH>\]/MZ80A_RFS/software/roms |
| \<CPM\> | \[\<ABS PATH>\]/MZ80A_RFS/software/CPM |
| \<tools\> | \[\<ABS PATH>\]/MZ80A_RFS/software/tools |
| \<src\> | \[\<ABS PATH>\]/MZ80A_RFS/software/src |
| \<MZF\> | \[\<ABS PATH>\]/MZ80A_RFS/software/MZF |
| \<MZB\> | \[\<ABS PATH>\]/MZ80A_RFS/software/MZB |
## Tools
All development has been made under Linux, specifically Debian/Ubuntu. I use Windows for flashing the RAM's and using the GUI version of CP/M Tools but havent dedicated any time into building the RFS 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 work with the CP/M software andCP/M disk images, you will need to obtain and install the following tools.
[Z80 Glass Assembler](http://www.grauw.nl/blog/entry/740/) - A Z80 Assembler for converting Assembly files into machine code.<br>
[samdisk](https://simonowen.com/samdisk/) - A multi-os command line based low level disk manipulation tool.<br>
[cpmtools](https://www.cpm8680.com/cpmtools/) - A multi-os command line CP/M disk manipulation tool.<br>
[CPMToolsGUI](http://star.gmobb.jp/koji/cgi/wiki.cgi?page=CpmtoolsGUI) - A Windows based GUI CP/M disk manipulation tool.<br>
[z88dk](https://www.z88dk.org/forum/) - An excellent C development kit for the Z80 CPU.<br>
[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.<br>
## Software
Building the software and final ROM images can be done by cloning the [repository](https://github.com/pdsmart/MZ80A_RFS.git) and running some of the shell scripts and binaries provided.
The RFS is built as follows:
1. Make the RFS binary using \<tools\>/assemble_rfs.sh, this creates \<roms\>/rfs.rom for the User Bank Flash RAM and \<roms\>/rfs_mrom.rom for the Monitor Bank Flash RAM.
2. Make the original MZ80A monitor roms using \<tools\>/assemble_roms.sh, this creates \<roms\>/monitor_SA1510.rom and \<roms\>/monitor_80c_SA1510.rom for the Monitor Bank Flash RAM.
3. Make the rom images using \<tools\>/make_roms.sh, this creates \<roms\>/USER_ROM_256.bin for the User Bank Flash RAM and \<roms\>/MROM_256.bin for the Monitor Bank Flash RAM.
The rom images also contain a packed set of MZF applications found in the \<MZF\> directory. Edit the script \<tools\>/make_roms.sh to add or remove applications from the rom images.
The above procedure has been encoded in a set of shell scripts and C tools, which at the simplest level, is to run these commands:
````bash
cd <software>
tools/assemble_cpm.sh
tools/assemble_rfs.sh
tools/assemble_roms.sh
tools/make_cpmdisks.sh
tools/make_roms.sh
tools/make_sdcard.sh
````
The output of the above commands are ROM images \<roms\>/MROM_256.bin and \<roms\>/USER_ROM.256.bin which must be flashed into 512Kbyte Flash RAMS and inserted into the sockets on the
RFS adapter.
The applications which can be stored in the Flash RAMS are located in the \<MZF\> directory. In order to use them within the Flash RAM's, the applications need to be converted into sector rounded binary images and stored in the
\<MZB\> directory. The tool \<tool\>/processMZFiles.sh has been created for this purpose. Simply copy any MZF application into the \<MZF\> directory and run this tool:
````bash
cd <software>
tools/processMZFfiles.sh
````
The files will be converted and stored in the \<MZB\> directory and then used by the \<tools\>/make_roms.sh script when creating the ROM images. The \<tools\>/make_roms.sh script lists all the applications to be added into the
Flash RAM's and it will pack as many as space permits. To ensure your application appears in the Flash RAM, add it to the top of the list (just the filename not the .MZF extension), ie:
````bash
Edit the file <tools>/make_roms.sh
Locate the line: ROM_INCLUDE=
Below this line, add your application in the format: ROM_INCLUDE+="${MZBPATH}/<YOUR APPLICATION>.${SECTORSIZE}.bin"
ie. ROM_INCLUDE+="${MZB_PATH}/A-BASIC_SA-5510.${SECTORSIZE}.bin:"
Save the file and run the commands above to build the MonitorROM and USERROM's.
````
The SD Card image is created by the \<tools\>/make_sdcard.sh script and in its basic form creates an image which can be directly copied onto an SD Card. This image contains the SD Card Filing System which is populated with
MZF applications from the \<MZF\> directory. Edit the \<tools\>/make_sdcard.sh script to add/remove MZF applications which are installed into the SDCFS. CP/M images are also added to the SD Card and this is covered in the
[CP/M](sharpmz-upgrades-cpm/) section.
## SD Card
A recent addition to the Rom Filing System is an SD Card. In hardware it is implemented using the bitbang technique and provides performance comparable with a floppy disk without the seek overhead or interleave
times, but in all honesty, this would be better catered for by dedicated shift registers in order to gain performance on par with the ROM drives.
I worked on using the [Petit FatFS by El CHaN](http://elm-chan.org/fsw/ff/00index_p.html) for the SD Card filing system, which is excellent having previously used the full Fat version with my ZPU project, but the Z80 isnt the best
architecture for code size when using C. In the repository in \<src\>/tools is my developments along this line with a C program called 'sdtest' and a modularized PetitFS along with manually coded Z80 assembler to handle the bitbang
algorithm and SD Card initialisation and communications. The program compiles into an MZF application and when run performs flawlessly. The only issue as mentioned is size and when your limited to 2K and 4K banked roms with a 12K
filing system you have an immediate storage issue. It is feasible to build PetitFS into a set of ROM banks using the z88dk C Compiler which supports banked targets and __far constructs but it would be a lot of effort for something
which really isnt required.
I thus took a step back and decided to create my own simple filing system which is described below. This filing system is used for Sharp MZ80A MZF applications and is for both read and write operations.
### SD Card Filing System
The SD Card Filing System resides at the beginning of the SD Card and is followed by several CPM disk drive images. The SDCFS image is constructed of a directory plus 256 file blocks. The directory can contain upto 256 entries,
each entry being 32 bytes long. The SDCFS directory entry is based on the MZF Header format and is as follows:
| FLAG1 | FLAG2 | FILE NAME | START SECTOR | SIZE | LOAD ADDR | EXEC ADDR | RESERVED |
|--------|--------|-----------|--------------|---------|-----------|-----------|----------|
| 1 Byte | 1 Byte | 17 Bytes | 4 Bytes | 2 Bytes | 2 Bytes | 2 Bytes | 3 Bytes |
| Parameter | Description |
| ------------- | --------------------------------------------------------------------------------------------- |
| FLAG1 | BIT 7 = 1, Valid directory entry, 0 = inactive. |
| FLAG2 | MZF Execution Code, 0x01 = Binary |
| FILENAME | Standard MZF format filename. |
| START SECTOR | Sector in the SD card where the program starts. It always starts at position 0 of the sector. |
| SIZE | Size in bytes of the program. Each file block occupies 64Kbyte space (as per a tape) and this parameter provides the actual space occupied by the program at the current time. |
| LOAD ADDR | Start address in memory where data should be loaded. |
| EXEC ADDR | If a binary then this parameter specifies the location to auto execute once loaded. |
| RESERVED | Not used at the moment. |
Each file block, 1 per directory entry, is 64K long which is intentional as it keeps a fixed size which is in line
with the maximum tape (CMT) length and can be freely read/written to just as if it were a tape. This allows for easy
use within tape based applications such as Basic SA-1510 or for copying SD Card \<-\> CMT.
The remainder of the SD Card is filled with 16MByte CPM Disk drive images. Each image is organised as 32 (512byte) Sectors x 1024 tracks
and 1 head. Each image will be mounted in CPM under its own drive letter.
Visually, the SD Card is organised as follows:
```
SECTOR FUNCTION
00000000 ---------------------------------------------------------------------------
| ROM FILING SYSTEM IMAGE |
| |
00000000 | RFS DIRECTORY ENTRY 000 (32BYTE) |
| .. |
| .. |
00001FE0 | RFS DIRECTORY ENTRY 255 (32BYTE) |
00002000 ---------------------------------------------------------------------------
| RFS FILE BLOCK 0 |
00003000 ---------------------------------------------------------------------------
...
00FF0000 ---------------------------------------------------------------------------
| RFS FILE BLOCK 255 |
01000000 ---------------------------------------------------------------------------
01000000 ---------------------------------------------------------------------------
| |
| CP/M DISK IMAGE 0 |
| |
02000000 ---------------------------------------------------------------------------
| |
| CP/M DISK IMAGE 1 |
| |
03000000 ---------------------------------------------------------------------------
| |
| CP/M DISK IMAGE 2 |
| |
XX000000 ---------------------------------------------------------------------------
| |
| CP/M DISK IMAGE <n> |
| |
---------------------------------------------------------------------------
```
#### To Do #### To Do
1) Remake the PCB to use standard DIP Flash RAM packages.<br/> 1) Remake the PCB to use standard DIP Flash RAM packages and the updated hardware plus SD Card hardware.<br/>
2) Add Mux to allow Z80 writing into the Monitor ROM Flash.<br/> 2) Add Mux to allow Z80 writing into the Monitor ROM Flash.<br/>
3) Add a coded latch such that it is possible to write to the Flash RAM (didnt originally consider writing to the Flash RAM) without upsetting the page register.<br/> 3) Add a coded latch such that it is possible to write to the Flash RAM (didnt originally consider writing to the Flash RAM) without upsetting the page register.<br/>
4) Write routines such that any files (ie. Basic) can be stored in the RFS and retrieved by an application such as Basic. Currently the stored files are only accessible to the Monitor.<br/> 4) Update Basic SA-5510 so that it loads/saves from SD Card.<br/>
5) Write routines which allow storing/saving of files into the RFS via the Flash RAM writing mechanism (needs 3 fixing first).<br/>
### Images of the RFS Command Output
#####
![alt text](https://github.com/pdsmart/MZ80A_RFS/blob/master/docs/IMG_9784.jpg)
Issuing the 'I' command to list the Rom directory contents. Note the hex number followed by the MZF filename. The hex number can be used as a quick way to reference a file.
![alt text](https://github.com/pdsmart/MZ80A_RFS/blob/master/docs/IMG_9789.jpg)
Directory listing in 80 Character mode.
![alt text](https://github.com/pdsmart/MZ80A_RFS/blob/master/docs/IMG_9788.jpg)
Issuing a Load command to load Basic SA-5510 using the short hex number abbreviation.
![alt text](https://github.com/pdsmart/MZ80A_RFS/blob/master/docs/IMG_9790.jpg)
Load command in 80 character mode.
### Images of the RFS Daughter Board
#####
![alt text](https://github.com/pdsmart/MZ80A_RFS/blob/master/docs/IMG_9625.jpg)
The topside without the Flash RAM's being sited. The first PCB was intended to use a Skinny DIP device but I ordered the wrong part so had to make an adapter to fan out the Skinny DIP footprint to a standard DIP footprint.
![alt text](https://github.com/pdsmart/MZ80A_RFS/blob/master/docs/IMG_9626.jpg)
The underside has 2x28pin adapters such that the board plugs into the original Monitor/User ROM sockets. This keeps the upgrade reversible and doesnt change the original motherboard.
![alt text](https://github.com/pdsmart/MZ80A_RFS/blob/master/docs/IMG_9624.jpg)
The RFS daughter board plugged into the original motherboard via the Monitor/User ROM sockets.
## Credits ## Credits
Where I have used or based any component on a 3rd parties design I have included the original authors copyright notice. Where I have used or based any component on a 3rd parties design I have included the original authors copyright notice within the headers or given due credit. 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 ## Licenses
This design, hardware and software, is licensed under th GNU Public Licence v3. This design, hardware and software, is licensed under the GNU Public Licence v3.
### The Gnu Public License v3
The source and binary files in this project marked as GPL v3 are free software: you can redistribute it and-or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
The source files are distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/.

492
README_CPM.md Normal file
View File

@@ -0,0 +1,492 @@
## Overview
Linux and Windows are now the staple operating systems in use but years ago it all started with Digital Research creating the Control Program/Monitor (CP/M). CP/M was one of the first real operating systems for Microcomputers
providing common means to run applications across varying hardware. Any machine running CP/M has access to thousands of programs and thus started the quest to get CP/M running on the Sharp MZ80A.
A version of CP/M was created by Micro Technology for the Sharp MZ80A, but as it lacked an 80 column screen, it wasnt so useful without an upgrade. A look around showed third parties such as Kuma developed an 80 column
upgrade which you could later source from the SUC, but CP/M on the MZ80A, although mentioned in many articles is actually quite elusive to obtain in 2020. Various excellent sites such as original.sharpmz.org offer the 80K/80B/800
versions but not for the MZ80A.
I developed the 80 Column colour upgrade board and the Rom Filing System with the primary focus to realise CP/M on the MZ80A. It is very easy in the FPGA based hardware emulator project to add changes to accommodate various
column outputs, colour or graphics, but to do it on the actual original hardware making minimal changes to a vintage machine was more of a challenge and also something of a personal desire since first owning this machine in 1983.
Most of the upgrades you see from the past require cuts and links to the original PCB which I specifically didnt want, I want to keep the original hardware as Sharp made it! The only change I make in my upgrades to the original
PCB is to socket a chip (IC8 74LS165 video shift register) which could quite easily be done if it failed in use and was replaced, that way the machine is 100% original and can be returned to it's original factory state very easily.
Thus I started to try and get CP/M working, even with a plethora of information on the net, wasnt an easy task. Firstly, obtaining Micro Technology's version of CP/M for the MZ80A proved very elusive so I fell back to the MZ80K
and MZ80B versions. I then hit upon the various odd-ball disk formats, with the MZ80A designed to read inverted data adding to the fray. Cut a long story short, I ended up deciding to write my own rom based version of the CBIOS
and blending it in with the BDOS+CCP of CP/M v2.23. This section details the information on this work accordingly.
## CP/M Boot Process
Booting CP/M occurs in two phases:
1. Using the original AFI Floppy Disk control software, read in an inverted boot sector, check it contains at 0x0000 the control code 0x02 + "IPLPRO", then pass control to the encapsulated boot loader
2. Load, starting at 0x9C00, the CCP, BDOS and CBIOS. The CBIOS now takes control and applies a different disk format and uses different FDC Controller logic (ie. re-inverts the data).
To this end I disassembled the MZ80A AFI ROM (which can be found in the repository) to understand what actions it was performing. The initial load checks to see if the disk is a bootable disk under the MZ80A. For the MZ80K the marker
for a bootable disk (besides the format being very different and not inverting the data) was for 01 + IPLPRO in the starting bytes of the first sector. For the MZ80B this was 03 + IPLPRO.
As I didnt have an MZ80A copy of CP/M I tried to get the MZ80K version to load, but the non-inverted data meant I had to convert an MZ80K boot disk into an MZ80A format. Once this was done, I tried to boot CP/M but there were
incompatibilities, for example the disk controller!! I then spent time looking at the MZ80B and MZ800 versions of Micro Technologies CP/M, which again used differing disk formats and in the end I decided the best approach would
be to build a custom CP/M and write my own CBIOS.
## CBIOS
CP/M is built from 3 distinct modules, CCP (Console Command Processor), BDOS (Basic Disk Operating System) and CBIOS (Custom Basic Input Output System). Generally CCP + BDOS are standard and the CBIOS is customised according
to the underlying hardware.
All 3 components would be bootstrapped off the floppy disk, loaded into memory (0x9C00 for the MZ80K/A) and control passed to the CBIOS which would setup the machine before handing control to the CCP. Under normal working conditions,
any loaded application would call the BDOS to perform services such as writing to the console, getting key input, disk access etc from a well defined API but if it didnt need the BDOS services it could call the CBIOS directly using
it's API and in turn could use the CCP+BDOS RAM to gain more program space. When an application completes, it jumps to vector 0x0000 initiating a Warm start involving reloading of the CCP+BDOS.
The way CPM is written it doesnt lend itself to be stored in ROM as it self modifies/uses embedded variables but for the CBIOS it is a different story. It is possible to place the CBIOS in ROM to gain more RAM and having access
to the Rom Filing System with its paged ROM banks, this is the route I took.
In order to create a CBIOS you have to provide the following API methods:
| API Method | Description |
|------------|------------------------------------------------------------------------------------|
| BOOT | Cold start, initiate all hardware prior to invocation of the CCP. |
| WBOOT | Warm start, set back any hardware changes and then reload CCP+BDOS before invocation of CCP. |
| CONST | Console Status, see if a keyboard key entry is waiting to be read. |
| CONIN | Console Input, fetch a key from the keyboard, wait if non available. |
| CONOUT | Console Output, output a character to the screen. |
| LIST | List Device Output, output a character to the listing device (ie. Printer). |
| PUNCH | Punch Device Output, output a character to the puch device (yep, punch tape or cards were used in the 70's)! |
| READER | Reader Input, input a character from the Reader device (ie. paper tape)! |
| HOME | Move the head of the currently selected disk to Track 0. |
| SELDSK | Select/activate a disk. |
| SETTRK | Set the disk track for the next read/write operation. |
| SETSEC | Set the disk sector on the selected track for the next read/write operation. |
| SETDMA | Set the Disk Memory Address, the location where data will be read/stored. |
| READ | Read a disk sector. |
| WRITE | Write a disk sector. |
| LISTST | List Device Status, see if the listing device is ready to accept a new character. |
| SECTRN | Sector Translate, Logical to Physical sector translation to adapt to specific hardware or improve responsiveness of the disk subsystem. |
Looks a simple requirement but then you have to consider that a machine such as the MZ80A doesnt have it's own BIOS and the firmware in it's ROM when running under CP/M is relocated to 0xC000 and thus unuseable. Also the Floppy
Control Firmware is very basic and only deals with bootstrapping a disk.
A futher requirement above the basic mechanisms for character input/output CP/M provides, is that most applications expect a Smart Terminal to be sat in front of the CP/M machine to provide advanced Screen and keyboard functionality.
This would normally be in the form of a Terminal such as a DEC VT52 or VT100. As the MZ80A has it's own screen and keyboard, this smart functionality has to be written.
Thus in order to write the CBIOS, the following firmware sub-modules need to be coded:
| Sub-Module | Description |
|-------------------- |------------------------------------------------------------------------------------|
| Basic Screen I/O | The low level functions to place a character on the screen, clear the screen etc. |
| Advanced Screen I/O | Intelligence to position display output, clear screen portions, special attributes such as Bold etc. |
| Keyboard I/O | Scan and return keycodes, map to ASCII as required. |
| Disk I/O | Provide facilities to read and write multiple disk sectors. |
Having previously disassembled the Sharp SA-1510 monitor I had a good starting position to provide the basic Screen and Keyboard facilities, disassembling the Floppy Disk AFI firmware provided an insite into the code required to
read a floppy disk, more especially the short falls. The MZ80A is a 2MHz computer and does not have the speed to service the disk input/output stream, it has to rely on a piece of hardware which pages a ROM bank based on the Data Request/Ready
signal of the FDC. Thus the FDC components required significant work. For the Advanced Screen I/O, I decided to use the ANSI standard and sourced Ewen McNeill's Amstrad CPC Terminal Emulator. I initially thought it would be a simple extract and
drop in of his ANSI parser but this turned out to be a major amount of work. Sometimes the easiest option is the hardest!!
All this functionality takes space and it has been apportioned as follows:
| ROM | Address | Description |
|--------------- | -------------- |------------------------------------------------------------------------------------|
| 4K MROM (relocated Monitor ROM from 0x0000 - 0x0FFF) | 0xC000 - 0xCFFF | CBIOS providing the CP/M API, initialisation routines, ROM Disk controller routines, Interrupt routines.
| 2K Paged ROM | 0xE800 - 0xEFFF, Bank 8 | Basic Sound and Melody, RTC, Keyboard and helper functionality. |
| 2k Paged ROM | 0xE800 - 0xEFFF, Bank 9 | Screen I/O and ANSI Terminal Parser. |
| 2k Paged ROM | 0xE800 - 0xEFFF, Bank 10 | SD Card Controller functionality. |
| 2k Paged ROM | 0xE800 - 0xEFFF, Bank 11 | Floppy Disk Controller functionality. |
#### *CPM Disk Drives*
As this implementation of CPM and Custom BIOS uses 3 different disk drive controllers, some of which may not be present at any one time, the drives are dynamically created within CPM during the cold boot.
The ordering of the drives is shown in the following table:
| Rom Drive # | Present | 0 | 1 | 2 | Present | 0 | 1 | 2 |
|--------------|---------|-----------|---------|---------|----------|-------------|-----------|----------|
| Rom Drive | n/a | | A | A,B | n/a | | A | A,B |
| Floppy Disk | Yes | A,B | B,C | C,D | No | | | |
| SD Card | Yes | C,D,E,F | D,E,F | E,F,G | Yes | A,B,C,D,E | B,C,D,E | C,D,E,F |
| SD Card | No | | | | Yes | | | |
The limit on the number of drives is CPM (limit of 16 drives) and the amount of RAM allocated to the drives, governed by the variable 'CSVALVEND - CSVALVMEM' which is set in the CPM_Definitions.asm file in the repository. The drive
allocation is dynamic, so more memory allocated will see more drives available. The SD Card can contain 100's of 16MB SD Disk Drives, so the issue is purely RAM assigned for their use.
#### *Features*
Besides the standard BIOS functionality, the following features have been added to the CBIOS.
- Real Time Clock with 50mS granularity
- Interrupt driven keyboard with buffer and auto repeat.
- Tri-mode key lock, Normal, Caps Lock, Shift Lock
- Ansi Terminal Functionality
- Re-targettable Floppy Disk drives of size 1.44M, 720K & 320K
- Re-targettable ROM drives of size 240K (changeable via config)
- Re-targettable SD Card 16Mb Hard disks.
- Exit to Monitor via SHIFT+GRAPH+BREAK.
## Building CPM
Building CP/M involves assembling the Z80 Assembly language source into a machine code binary and then creating a boot disk, or in this implementations case, a ROM based CBIOS and an
MZF format bootable application which is stored in ROM.
To accomplish it you need several tools and at the moment it is quite a manual process.
## Paths
For ease of reading, the following shortnames refer to the corresponding path in this chapter.
| Short Name | |
|------------------|----------------------------------------------------------------------------|
| \[\<ABS PATH>\] | The path where this repository was extracted on your system. |
| \<software\> | \[\<ABS PATH>\]/MZ80A_RFS/software |
| \<roms\> | \[\<ABS PATH>\]/MZ80A_RFS/software/roms |
| \<CPM\> | \[\<ABS PATH>\]/MZ80A_RFS/software/CPM |
| \<tools\> | \[\<ABS PATH>\]/MZ80A_RFS/software/tools |
| \<MZF\> | \[\<ABS PATH>\]/MZ80A_RFS/software/MZF |
| \<MZB\> | \[\<ABS PATH>\]/MZ80A_RFS/software/MZB |
## Tools
All development has been made under Linux, specifically Debian/Ubuntu. I use Windows for flashing the RAM's and using the GUI version of CP/M Tools but havent dedicated any time into building the RFS 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 work with the CP/M software andCP/M disk images, you will need to obtain and install the following tools.
[Z80 Glass Assembler](http://www.grauw.nl/blog/entry/740/) - A Z80 Assembler for converting Assembly files into machine code.<br>
[samdisk](https://simonowen.com/samdisk/) - A multi-os command line based low level disk manipulation tool.<br>
[cpmtools](https://www.cpm8680.com/cpmtools/) - A multi-os command line CP/M disk manipulation tool.<br>
[CPMToolsGUI](http://star.gmobb.jp/koji/cgi/wiki.cgi?page=CpmtoolsGUI) - A Windows based GUI CP/M disk manipulation tool.<br>
[z88dk](https://www.z88dk.org/forum/) - An excellent C development kit for the Z80 CPU.<br>
[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.<br>
## Software
Building the software images can be done by cloning the [repository](https://github.com/pdsmart/MZ80A_RFS.git) and running some of the shell scripts and binaries provided.
| Script | Description |
|------------------ | ------------------------------------------------------------------------------------------------------------------------ |
| assemble_cpm.sh | A shell script to build the CPM binary, the CPM MZF format application for loading via RFS and the CPM ROM Drives 0 & 1 |
| assemble_rfs.sh | A bash script to build the Rom Filing System ROM images. |
| assemble_roms.sh | A bash script to build all the standard MZ80A ROMS, such as the SA-1510 monitor ROM. |
| make_roms.sh | A bash script to build the RFS ROMS suitable for programming in the 512KByte Flash RAMS. These images contain the banked RFS ROMS, the various system ROMS such as SA-1510 and all the MZF programs to be loaded by the RFS. |
| make_cpmdisks.sh | A bash script to build a set of CPM disks, for use as Raw images in the SD Card or Rom drives and as CPC Extended Disk Formats for use in a Floppy disk emulator or copying to physical medium. |
| make_sdcard.sh | A bash script to create an SD card image combining the RFS Image and several CPM disk drives. This image is then binary copied onto the SD card and installed into the RFS SD Card reader. |
| mzftool.pl | A perl script to create/extract and manipulate MZF images. |
| processMZFfiles.sh| A bash script to convert a set of MZF programs into sectored images suitable for use in the Rom Filing System ROMS. |
| sdtool | A binary created in the src/tools repository which builds the RFS SD Card image, creating a directory and adding MZF/Binary applications into the drive image. |
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 ROM and 4 banked 2K ROMS. These
are generated for adding into the RFS Banked Monitor ROM and the Banked User ROM.
3. upto 2 (currently) Read Only CPM ROM Drive's which can be assigned to any CP/M drive
letter.
4. conversion of the binaries generated in 1. and 3. into sectored MZF images suitable
for adding directly into the Rom Filing System as just another program.
All of the above are encoded into the assemble_cpm.sh bash script which can be executed as follows:
````bash
cd <software>
tools/assemble_cpm.sh
````
The script is currently set to generate 1 Read Only CPM ROM Drive. To add a second CPM ROM Drive, follows these instructions:
````bash
1. Edit the <tools>/make_cpmdisks.sh script and change the
variable:
from BUILDCPMLIST="cpm22 CPM_RFS_1"
to BUILDCPMLIST="cpm22 CPM_RFS_1 CPM_RFS_2"
change the variable:
from SOURCEDIRS="CPM_RFS_[1] CPM[0-9][0-9]_* CPM_MC_5 CPM_MC_C? CPM_MC_D? CPM_MC_E? CPM_MC_F? CPM[0-9][0-9]_MZ800*" to
to SOURCEDIRS="CPM_RFS_[1-2] CPM[0-9][0-9]_* CPM_MC_5 CPM_MC_C? CPM_MC_D? CPM_MC_E? CPM_MC_F? CPM[0-9][0-9]_MZ800*"
2. Create a directory (if it doesnt exist):
<CPM>/CPM_RFS_2
3. Fill the directory with required CPM files to be placed in the ROM.
4. Build the image by running the make_cpmdisks.sh script or as part of the sequence of commands listed below.
````
In order to use CPM, it is necessary to create the MonitorROM and USERROM images which can be programmed into the 2x512KByte Flash RAMS. Issue the following commands to build CPM along with all the RFS, ROMS and Applications in ROM:
````bash
cd <software>
tools/assemble_cpm.sh
tools/assemble_rfs.sh
tools/assemble_roms.sh
tools/make_cpmdisks.sh
tools/make_roms.sh
tools/make_sdcard.sh
````
The output of the above commands are ROM images \<roms\>/MROM_256.bin and \<roms\>/USER_ROM.256.bin which must be flashed into 512Kbyte Flash RAMS and inserted into the sockets on the
RFS adapter.
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 SD Card image can be found in \<roms\>/SHARP_MZ80A_RFS_CPM_IMAGE_1.img which contains the RFS Disk image \<roms\>/SHARP_MZ80A_RFS_IMAGE_1.img at the start followed by
seven CPM format drive images which, as per above, are stored in \<CPM\>/SDC16M/RAW. These images are built from the directories in \<CPM\> but are manually added in to the
final images by hardcoding in the script make_cpmdisks.sh.
The applications which are stored in the ROM drives are located in the \<MZF\> directory. Copy any applications you want into this directory then issue the following command to process them into sector rounded images
stored in the \<MZB\> directory.
````bash
cd <software>
tools/processMSFfiles.sh
````
The actual applications which are built into the ROM are selected in the \<tools\>/make_roms.sh script. This script lists all the applications required and it will pack as many as space permits into the ROM. To
ensure your application appears in ROM, add it to the top of the list (just the filename not the .MZF extension), ie:
````bash
Edit the file <tools>/make_roms.sh
Locate the line: ROM_INCLUDE=
Below this line, add your application in the format: ROM_INCLUDE+="${MZBPATH}/<YOUR APPLICATION>.${SECTORSIZE}.bin"
ie. ROM_INCLUDE+="${MZB_PATH}/A-BASIC_SA-5510.${SECTORSIZE}.bin:"
Save the file and run the commands above to build the MonitorROM and USERROM's.
````
## Disk Formats
As I found out, there are 100's of CP/M disk formats and the Sharp series alone implements 2-3 per machine. In deciding on what format to
use for this implementation of CP/M I looked at the existing formats. Not having access to original Sharp MZ80A disks and with them being
in inverted non-standard format anyway, the MZ80B being similar to the MZ80A but slightly higher capacity, the MZ800 being a hybrid and the
MZ80K being low capacity, I opted to use standard formats for 1.44MB, 720K 3.5" Floppies, the same physical format as the Sharp MZ80A disks
and the ROM based 240K Rom Drive.
The formats I am using can be manipulated by cpmtools using the following diskdefs definitions, place the above into the diskdefs file
located with the cpmtools or CPMToolsGUI to use:
````bash
# 320K Disk for the MZ80A - Same format as the MZ800
# but implements a cylinder in uniform manner (ie. 1 cyl
# = 1 track x 2(heads) where as the MZ800 implements as
# 160 tracks, 80 x Head 1 0->79 then 80 x Head 2 80->159.
diskdef MZ80A-A
seclen 256
tracks 40
sectrk 32
blocksize 2048
maxdir 64
skew 0
boottrk 1
os 2.2
end
# A standard format 1.44Mb Floppy format for the MZ80A
diskdef MZ80A-1440
seclen 512
tracks 80
sectrk 36
blocksize 2048
maxdir 128
skew 0
boottrk 0
os 2.2
end
# A standard format 720K Floppy format for the MZ80A.
diskdef MZ80A-720
seclen 256
tracks 80
sectrk 36
blocksize 2048
maxdir 128
skew 0
boottrk 0
os 2.2
end
# A 240K Rom Filing System ROM Drive image.
diskdef mz80a-rfs
seclen 128
tracks 15
sectrk 128
blocksize 1024
maxdir 32
skew 0
boottrk 0
os 2.2
end
# A 16Mb fixed disk SD Card Image.
diskdef MZ80A-SDC16M
seclen 512
tracks 1024
sectrk 32
blocksize 8192
maxdir 512
skew 0
boottrk 0
os 2.2
end
````
Within CP/M these physical disk formats are represented in the disk parameter block as follows. Normally you dont need to be concerned
about these settings or the above diskdefs, just useful to know if you need to add your own custom format:
| Definition | MZ80A 320K | Rom Filing System | 1.44MB 3.5" | 720K 3.5" | 16MB SD Card Image |
| SPT | 64 | 128 | 144 | 72 | 128 |
| BSH | 4 | 3 | 4 | 4 | 6 |
| BLM | 15 | 7 | 15 | 15 | 63 |
| EXM | 1 | 0 | 0 | 0 | 3 |
| DSM | 155 | 240 | 719 | 359 | 2047 |
| DRM | 63 | 31 | 127 | 127 | 511 |
| AL0 | 128 | 128 | 192 | 192 | 192 |
| AL1 | 0 | 0 | 0 | 0 | 0 |
| CKS | 16 | 8 | 32 | 32 | 0 |
| OFF | 1 | 0 | 0 | 0 | 0 |
In order to use existing Sharp CP/M programs it will be necessary to extract the programs off the disk and add to a format recognised by this implementation. To
this end, the following sections describe how to extract data off the relevant machines disks.
### Creating a CPM Disk
In my development I used a Lotharek HxC Floppy Emulator connected to a Sharp MZ80-AFI interface card. Using this arrangement it is possible to emulate any disk drive that the
Sharp MB8866 Floppy Disk Controller can talk to. This is how I arrived at and tested the 3.5" formats, as these drives are still obtainable and have sufficient capacity
for most CP/M operations.
In order to create a CP/M Disk which can be used on the Sharp MZ80A with this implementation of CP/M, you need to add the above definitions to your cpmtools diskdefs file. Once
added, either copy one of the blank images in \<CPM\>/BLANKFD to a new name and use as your target disk or create one from within CPMTools using
the disk definition. You then add required programs to the new disk which in CPMToolsGUI this is just a drag and drop procedure.
In order to use the new raw CP/M image in the Floppy Emulator or a real Floppy Disk drive, it is necessary to convert the raw image into a format that most
Floppy disk tools can read and write onto a floppy. In the case of the Lotharek Floppy Emulator, using their tool HxCFloppyEmulator v2.2.2.1 via the Load and
Export to HFE will generate a suitable SD image to mimic a real floppy.
To convert the image, use one of the following:
For 1.44MB Drives use:
./samdisk copy <RAW IMAGE FILE, ie. CPM00_SYSTEM.RAW> <DSK IMAGE FILE, ie.CPM00_SYSTEM.DSK> --cyls=80 --head=2 --gap3=78 --sectors=36 --interleave=4
Samdisk will automatically recognise the format from the size of the file, ie. 1474560 bytes
For 720K Drives use:
./samdisk copy <RAW IMAGE FILE, ie. CPM00_SYSTEM.RAW> <DSK IMAGE FILE, ie.CPM00_SYSTEM.DSK> --cyls=80 --head=2 --gap3=78 --sectors=36 --size=2 --interleave=4
Samdisk will automatically recognise the format from the size of the file, ie. 737280 bytes
For the MZ80A 320K Drives use:
./samdisk copy CPM00_320K_SYSTEM.RAW CPM00_320K_SYSTEM.DSK --cyls=40 --gap3=78 --head=2 --sectors=16
Samdisk will automatically recognise the format from the size of the file, ie. 327680 bytes
The RFS ROM Drive does not need conversion, the RFS functionality assumes a raw image.
NB. Dont use Samdisk v4, it has a bug where it will place a random sector at the start of the disk. Many hours debugging were lost due to this bug. Best to use
samdisk v3.8.8
The above samdisk commands create an Amstrad CPC Extended DSK format image which can be read and processed by Lotharek HxCFloppyEmulator or tools used to write
physical floppy disks.
### Extract MZ80A CP/M Disks
Under construction.
### Extract MZ80K CP/M Disks
Under construction.
### Extract MZ80B CP/M Disks
Under construction.
### Extract MZ800 CP/M Disks
The MZ800 series computers use a mixed format disk with the boot tracks using inverted data and the CP/M tracks using standard data. To make it worse, the ordering
of the tracks is such that they put head 0 as track 0-39 and head 1 as track 40-79. In order to use these disks, it is best to extract the data and copy it to one of the
formats I've created as I see no purpose in adding extra code to accommodate this strange format.
Use samdisk to convert the EDSK (Extended DSK format created for the Amstrad CPC Machine, most MZ800 disks appear to be in this format) into a RAW image.
````bash
samdisk copy <MZ800 DISK NAME>.DSK <MZ800 DISK NAME>.RAW --cyls=40 --head=2 --sectors=8 --size=256
````
Run the following bash commands to convert the RAW format disk obtained above into something which can be read by CPMTools.
````bash
mv <MZ800 DISK NAME>.RAW workingfile.raw
> total
dd if=workingfile.raw of=total count=8192 bs=1
for i in $(seq 8192 8192 327680); do
dd if=workingfile.raw of=blob skip=$i bs=1 count=4096
cat blob >> total
echo $i
done
for i in $(seq 12288 8192 327680); do
dd if=workingfile.raw of=blob skip=$i bs=1 count=4096
cat blob >> total
echo $i
done
mv total <MZ800 DISK NAME>.RAW
````
You will need the following diskdefs definition in order to read the data from the processed RAW image.
````bash
# Definition for the MZ800 CP/M Boot Disk. The reserved
# track is in inverted data format but this is skipped in
# CPM Tools.
diskdef mz800-BOOT
seclen 256
tracks 80
sectrk 16
blocksize 2048
maxdir 64
skew 0
boottrk 1
os 2.2
end
# Definition for the MZ800 CP/M Data disk. No reserved tracks.
diskdef mz800-DATA
seclen 256
tracks 80
sectrk 16
blocksize 2048
maxdir 64
skew 0
boottrk 0
os 2.2
end
````
### CP/M Archives
Included in the repository are a collection of CP/M programs for use on the MZ80A. These are selected programs and come from various CP/M archives and are assembled in directories with the naming convention CPM[0-9[0-9]_<Contents>.
Also included (and due credit and (C) for his work in assembling the archive) is from Grant Searle's MultiComp computer which is multiple computers in one (or multiple CPU types) and one of it's modes is to run CP/M. The archive of
Grant's is excellent and an ideal base to use CP/M on the MZ80A.
To build the archives into a set of 1.4MB Floppy images suitable for use in a 3.5" Drive or Floppy Emulator, run the command:
````bash
cd <software>
tools/make_cpmdisks.sh
````
The disks will be created in the directory: \<CPM\>/1M44/DSK.
This script also builds the 16MB SD Card drive images using a combination of the archives. The combination is hardcoded inside the script.
## Credits
Where I have used or based any component on a 3rd parties design I have included the original authors copyright notice within the headers or given due credit. 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
The source and binary files in this project marked as GPL v3 are free software: you can redistribute it and-or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version
3 of the License, or (at your option) any later version.
The source files are distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/.