MFT - a Multiple File Transfer Utility

BY LAWRENCE E. HUGHES Mycroft Labs, P.O. Box 6045 Tallahassee, FL 32301

This article describes the design and use of a utility which makes it practical to use a single disk drive on the Digital Research CP/M operating System. The entire source is included in this article, and is also available from the author on an 8" single density, 128-byte sector diskette, along with a few other public domain programs, from the above address, for $15. I hereby release MFT into the public domain, for use on any CP/M (or other) system. No right is granted for resale, with or without modifications.

This program is the fifth generation of a mechanism which can transfer files from one diskette to another on a single drive CP/M system. CP/M was originally designed for use on a two-drive system, and a reasonable mechanism was provided for transferring files from one diskette to another (PEP). Unfortunately, no provisions were made for owners of one-drive Systems. A temporary kludge is possible, which involves creating a "Pseudo drive" B. With this DIOS extension, anytime a new drive is accessed (via SELDSK), the user is prompted to mount the appropriate diskette in the one drive, and hit CR when it is mounted. This is simple enough to implement (if space is available in the DIOS), and it allows use of PIP to transfer files, but is somewhat clumsy to use, especially with PIP, which switches drives several times per file.

Since it was fairly expensive for me to upgrade my single drive Imsai FDC2-1 to a dual drive FDC2-1, I made several attempts to solve the file transfer problem, with increasing degrees of success. Since I now have a dual drive Tarbell system, and will probably not be making any further improvements to MFT, I have decided to release it into the public domain. There are probably a number of good folk out there who are currently using a single drive system, or else are holding off on disk altogether until they can afford two drives - this program is for you! Even owners of dual drive systems may wish to study this code as an example of a fairly elaborate utility which interfaces to CP/M.

The following discussion is intended to serve as a guideline to reading the code, and was never meant to be particularly useful without the accompanying code.

Note the use of meaningful symbols for the system interface addresses, BDOS function codes, and FCB field offsets. Note further that all I/O is done via BDOS calls.

The first step is to clear the 'break flags' (IBFLG and OBFLG). These will be explained later. The next step is to determine how much RAM is available for use as a memory buffer. This is calculated by finding the starting address of the BDOS (there is a pointer to it at 0006H), then subtracting from that the starting address of the memory buffer (which starts at the end of MFT). Note that the buffer size is then rounded down to the nearest multiple of 128 bytes. The user is then notified of how large the memory buffer is (in terms of 128 byte sectors).

At this point, the user is asked to mount the input disk and type CR. This allows the user to transfer files from a disk which does not contain MFT. Once a CR is typed, if IBFLG is set, MFT jumps to MFT2A. IBFLG will be set only if we left off reading a file in the middle at the end of the last pass. On the first pass, the routine CFNT will be called to create the File Name Table (FNT) from the list of ambiguous file names on the command line. The pointers IFNTP (pointer to the next file to input) and OFNTP (pointer to the next file to output) are reset to the start of the FNT.

At MFT2A, the memory buffer pointer (MBUFP) is reset to the start of the memory buffer (MBUF). MSIZE is set to the total amount of available memory in MBUF. If IBFLG is set, the rest of the partially read file from last pass is set up for reading where we left off. Otherwise, the next available file from the FNT is set up for reading, and the file size (FSIZE) is set to 0.

At MFT6, the current file is read into memory starting at MBUFP. As each sector is read into memory, FSIZE is incremented, MSIZE is decremented, and MBUFP is advanced 128 bytes. If MSIZE reaches 0, MBUF is full, hence IBFLG is set, and reading ceases. If either MBUF fills, or the end of the current file is read, MFT8 is reached.

At MFT8, the current file is closed, and the user is told how many sectors were read into MBUF. Then the file size (FSIZE) is stored in the FNT (along with the address at which this file started in MBUF). IFNTP is updated to point to the next file name to read. If IBFLG is not set, there must still be room in MBUF, so we loop back to MFT3 to read another file.

At MFT9, we either have ran out of files, or MBUF is full, so we ask the user to mount the output disk and type CR. When the CR is typed, we make the new disk Read/Write (via subroutine RESET). If OBFLG is set, we are appending to the end of a partially written file, hence we reopen it where we left off. If OBFLG is not set, we make a new file with the name from the FNT which is pointed to by OFNTP. Note that we force the $R/W and SDIR attribute flags low for 2.0 users (can't write to an R/O file). We fetch the file size (into FSIZE) from the FNT (at OFNTP). As each sector is written, FSIZE is decremented an MBUFP is advanced 128 bytes, until FSIZE is 0. At this point, the file is closed. We then tell the user how many sectors were written, and loop to MFTA. If the last file was only partially written (IBFLG was set), then we set OBFLG. When we finish the last file that was read into MBUF, we jump to MFTF. At this point, if IBFLG is set, we loop to MFT1 and repeat this cycle until all files in the FNT have been transferred.

The subroutines are not described in this article, since what they do is fairly obvious. Pay particular attention to GFN and CFNT: all the others are trivial.

Note that a fair amount of error handling is included at various points in MFT to catch things like 'No such files', 'disk full', etc. Note also that as files are transferred, the user is informed as to what is going on. This is especially important in a program such as this, where the machine could be busy for many minutes.

As far as style goes, note that the main program comes first, followed by all subroutines, then the messages, and finally by the RAM storage. The use of semicolons to denote comments is consistent throughout, and makes it easy to determine where the different parts of the program lie.

For further information on the conventions of interfacing to CP/M, consult the excellent Digital Research manual set.

To use MFT, merely type its name, followed by one or more ambiguous file names (using ? and/or * wildcards). You will be prompted to mount the input disk and type CR. At this time the disk with MFT may be removed, if the desired files are on a different disk. Once the input disk is mounted, the directory will be searched and a list of all file names which satisfy at least one of the ambiguous file names will be compiled. As many files as will fit into memory will then be read. You will then be asked to mount the output disk and type CR. Note that MFT can write on this disk without your having to 'log it in'. All data read from the input disk is then written to the output disk. If more files remain to be read, this cycle repeats until all files are transferred. As an example, MFT *.* may be used to copy all files from one disk to another.