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.

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 :-

• Creating disk images for the likes of The HxC Floppy Emulator (.hfe), Teledisk (.imd) or Andy's .mfloppy format
• Using PC based tools such as cpmtools, or Andy's cpmtools front end, cpmcbfs, to manipulate images on a PC

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.

Dave's Disk Format Changes

More Details coming soon . . . . . .

References : CPMTools Documentation