Computers Overview
Commodore PET
Sinclair ZX80
Sinclair ZX81
BBC Micro
Commodore 64
Sinclair ZXSpectrum
Memotech MTX
Memotech CP/M
  CP/M About
  CP/M Commands
  CP/M Cookbook
  CP/M Emulation
  CP/M Structure
  Custom FDX CP/M 
  Documents
  Software
      Disk Images
      Games
      Single Programs
      User Club Germany
      User Programs
Tatung Einstein
Atari ST
PDAs
DEC 3000 AXP
OpenVMS
Raspberry Pi

 

 
 

The Memotech MTX Series

Memotech FDX Multi-Format System

by David A Hill, 1986

 

A Customised FDX CP/M System

Back in the day, I made use of various bulletin boards (even running my own PC based Wildcat! BBS for a few years) and "met" a chap called Dave Hill who had built customised versions of the FDX CP/M Operating System.

The main FDX specific modification that Dave made was to modify the BIOS to increase the capacity of the FDX floppy drives by making changes to the disk format parameters. Dave also replaced the standard Memotech BDOS with BDOSZ Version 1.91, an improved CP/M type BDOS and the standard CP/M 2.2 CCP with CCPZ Version 2.x.

I lost touch with Dave Hill many years ago, so I have not been able to get permission from Dave to make his work available on the website, but as he shared it with me, then I assume that he would have no problem with this.

Dave, in the unlikely event that you come across this, then please get in touch.

 

An Alternative FDX BDOS

The advantages of BDOSZ are described in BDOSZ191.DOC :

"BDOSZ is a CP/M type BDOS for Z80 systems which offers total CP/M 2.2 compatibility for the CCP and transient programs. BDOSZ does, however, offer advantages over the standard issue CP/M BDOS in that it attempts to be a little more user friendly by making most of the BDOS error conditions recoverable."

The BDOSZ document file also describes how to integrate the BDOSZ functionality into an existing CP/M system - as Dave did for the FDX.

 

An Alternative FDX CCP

The advantages of CCPZ are described in CCPZ-V2x.DOC and are summarised below :

"CCPZ - A rewrite of the Z80 Version of the CP/M CCP.

CCPZ is upward-compatible with the original CP/M Version 2.2 CCP, but provides many extensions, including :

  • The TYPE function can be made to page or not page its output at the user's discretion.
  • A LIST function is available which sends its output to the CP/M LST: Device and does NOT page.
  • The DIR command has been extended to allow the display of the system files or all files .
  • The ERA command now prints out the names of the files it is erasing."

The CCPZ document file also describes how to integrate the CCPZ functionality into an existing CP/M system.

 

An Alternative FDX BIOS

The biggest benefit that I gained from Dave's modifications were his changes to the BIOS to increase the capacity of the installed floppy disks.

The floppy disk drives supplied with my FDX were QumeTrak 142 drives, these are DS/DD, corresponding to Memotech Type 03 disks and having a physical format of 40 tracks, 16 sectors per track and 256 byte sectors per side, giving a formatted capacity of 320kbytes, i.e., (40 * 16 * 256 * 2) / 1024.

QumeTrak 142 drives were also used in IBM PCs; when used with MS-DOS/PC-DOS, they were formatted with 9 sectors of 512 bytes per track, giving a formatted capacity of 360kbytes. Given the limited capacity of the disks, it appears to have been very inefficient for Memotech not have have used this space in the FDX which would have given in increase in capacity of ~10%.

Dave modified the formatting used in the Memotech FDX version of CP/M to take advantage of this apparently wasted disk space, stretching it even further than the PC format to 10, 512 byte sectors per track, giving a formatted capacity of 400kbytes. Dave kindly provided me with copies of his customised system, which came in two versions which he called MEMO1+ and his Memotech MFS (Multi-Format System).

The MEMO1+ system configured the two physical drives as "A" and "B" with this format. The MFS configured drives "A" and "B" in the same way, but using the second physical disk, created logical drives with different formats, including drive "C" configured as a Memotech Type 03 and drive "D" configured as a Televideo 802.

Dave also developed configurations to support 80 track drives which would have given a corresponding increase in capacity for Memotech Type 07 drives, but as I did not have 80 track drives back then, I did not take up Dave's offer of copies of that configuration too. Unfortunately, I lost touch with Dave many years ago, so I don't have the relevant system files for 80 track drives.

Dave did give me copies of the source files for his system which I have managed to copy to SD card using my HxC floppy disk emulator. Unfortunately, a couple of the Library files have problems - a couple of the .MAC files are truncated, meaning that it is not possible for me to modify and rebuild the system, but Dave's system runs "as-is" on my FDX, albeit that I can't use it in a Type 07 configuration with my HxC disk emulator.

 

The rest of the information on this page is intended to provide a bit of background on

how CP/M disks are formatted and a description of Dave's BIOS modifications.

The information was put together as much for my education as anything else,

I believe it to be accurate, but if you spot any errors, please let me know

 

Background : The CP/M Disk Structure

The first version of CP/M used 8" disks which were managed by the BDOS, the disk format was hard coded, making it difficult to use other formats. From CP/M version 2.0, the disk parameters were configured in tables in the BIOS called :-

  • Disk Parameter Headers (DPH)

    • Each disk drive has an associated (16-byte) Disk Parameter Header that contains information about the disk drive and provides a scratch pad area for certain BDOS operations. The DPHs are stored in an array of 16 byte blocks from the first drive to the last, with the 7th entry () pointing to the address of the associated DPB.

    and

     

  • Disk Parameter Blocks (DPB)

    • The DPBs contain definitions of the attributes of a group of disks, including the number of 128 byte sectors per track. 

Regardless of the physical format of the disk, CP/M treats all disks as having 128 bytes per sector, and under CP/M 2.2, usually 26 sectors per track. The number of logical tracks is calculated by dividing the disk capacity (in bytes) by the sector size (128) multiplied by the number of sectors per track (26).

so, for example, a Memotech Type 07 disk having a formatted capacity of 655360, i.e., (80 * 16 * 256 * 2) bytes has a 655360 / (128 * 26), or 196 complete tracks - the fractional track (0.92) is unused and the number rounded down the the nearest integer.

The first two tracks on the disk are reserved system tracks, used for the CP/M CCP, BDOS and BIOS. The first sector on a CP/M 2.2 system disk is reserved for an optional software boot section. This feature was to support those disk controllers that were set up to bring Track 0, Sector 1 into memory at a specific location (often location 0000h). The program in this sector, called BOOT, had the responsibility for loading subsequent sectors into memory. On Memotech CP/M systems, this sector is not used and the boot ROM has the responsibility for loading the date from sector 2 onwards, into memory.

From sector 2, the first data is for the CCP, followed by the BDOS and finally the BIOS, all of which are contained in the first two tracks of a bootable disk. Although some disk formats had provision for non-bootable disks, in the Memotech implementation of CP/M, the tracks are always reserved for CP/M - there is no advantage to not making all of you FDX/SDX disks bootable, unless you add some of the utilities such as CONFIG, STARTUP, STAT, etc.

After the system tracks, there are a fixed number of sectors reserved for directory entries which contain the disk file names and sector allocation. A Type 03 disk has space for 64 directory entries of 32 bytes each, requiring 64 * 32 bytes, i.e., 2048 bytes or 16 sectors. The system and directory areas are not included in the useable free space reported by, for example, STAT.COM.

The structure of a directory entry is shown in the graphic and table below, it can be seen that the directory entry has provision for 16 bytes that contain pointers to the consecutive areas on the disk that make up the file. If the pointer referenced the sector number, since a byte can only store numbers between 0 and 255, the disk would be limited to 255 sectors, or 32kbytes - plainly, not enough.

To cater for higher disk capacities, the sectors are grouped into blocks, a block is the smallest allocatable storage unit on a disk and varies with disk capacity. CP/M supports block sizes of 1024, 2048, 4096, 8192 and 16384 bytes, a Memotech Type 03 disk for example, has a block size of 2048 bytes.

With space for only 16 pointers to 2kbyte blocks, the maximum file size would be limited 32kbytes, again, far to small to be adequate, the solution to this problem is the use of extents. In an extent file system, a file made up of a number of smaller elements are bound together into a larger structure known as an extent, meaning that larger files can be stored, or their storage is optimised by storing the data contiguously. Unlike extents in other file systems, under CP/M, although the extents appear contiguously as a single block in the directory, they do not necessarily correspond to a contiguous data-area on the disk.

Directory Entry structure as used in CP/M 2.2

Function Size Description
Entity Type 1 Byte E5h The directory slot is unused, 0 to 15 means the CP/M User number
Filename 8 Bytes Required, can be any printable 7 bit ASCII character except: < > . , ; : = ? * [ ]
File Ext(ension) 3 Bytes

Optional, if used, the same character constraints as filename apply

The 8th bit is used to denote the file status E0: read-only E1: system file E2: archived

Ex(tent) 1 Byte

Extent counter - Low Byte. Range 0 - 31

0 if the file is <16kbytes, otherwise, the extent number in the range 1 -31

S1 (Bc) 1 Byte Not used - set to 0
S2 1 Byte Extent counter - High Byte
RC 1 Byte

Record Counter - the number of 128 byte "records" in this extent

If RC is 80h, this extent is full and there may be another one on the disc.

Disk Map

(Allocation Block Pointers)

16 Bytes

If the disk capacity is less than 256 blocks, the AL pointers are interpreted as 16 byte-values, otherwise as 8 double- byte-values.

For example, a 3k file might have allocation 5, 6, 8, 0, 0 . . . . 0 - the first 1k is in block 5, the second in block 6, the third in block 8.

Total 32 Bytes  

 

Why do you need to know any of this?

In truth, you probably don't, particularly if you just want to use your original Memotech disks and format a few floppies in the same way. However, if you want to explore other options such as :-

then a knowledge of the physical and logical disk formatting is called for.

cpmtools  / cpmcbfs

Andy Key's cpmcbfs (for Windows) and cpmfuse (for Linux) are built on top of cpmtools and therefore use a disk definition file (diskdefs) to describe the CP/M disk format using the parameters shown in the table. Andy has provided a copy of the disk definitions for Memotech disks in the diskdefs file distributed with cpmcbfs/cpmfuse and I have worked out the appropriate entries for the MEMO1+ format.

 

diskdefs

parameter

name

Memotech

DAH

Type 03 Type 07

MEMO1+

Sector size in bytes seclen 128 128 128
Number of (logical) tracks tracks 123 192  
Number of (logical) sectors sectrk 26 26  
Block size blocksize 2048 2048  
Number of directory entries maxdir 64 128  
Logical sector skew skew 0 1 0+
Number of reserved system tracks boottrk 2 2 2
+ Determined by the value used when formatting the disk under MEMO1+ (I use 0)

 

 

Dave's Disk Format Changes

 

 

More Details coming soon . . . . . .

 

References : CPMTools Documentation

 

mailto: Webmaster

 Terms & Conditions