Although CP/M has by now established itself as the "standard"8-bit microprocessor operating system, this doesn't mean by a long shot that programs are easily transferrable from one computer running CP/M to another. The CP/M operating system includes within it a section known as the Basic I/O System or "BIOS" for short. This part of the system is very machine-dependent and is what adapts the other (standars) parts of CP/M to the particular hardware it is being used on. These machine-dependent parameters include things like the port addresses for keyboard and printer, the disk controller type and the size and format of the particular disk system involved. For this reason a version of CP/M with a BIOS written for, say, the North Star Horizon would be of no use on a Morrow Micro Decision or other system with even a slightly different hardware configuration.

Since it is often necessary and desirable to move a program from one system to another, a way must be found to overcome the differences in all these versions of what is the "standard" operating system. One way that allows a speedy transfer is to simply have a version of CP/M with a custom BIOS written for multiple disk systems. This would be used in a machine with two or more disk controllers operating at the same time. Each controller could have a drive connected to it and assigned a logical drive name, for example an 8-inch single density floppy might be Drive A, a North Star minidisk drive might be Drive B, a TRS-80 CP/M format disk drive might be Drive C, and so on. I think you can see right away that this isn't a very practical setup. One would have to have all these types of disk controller active in the same machine at the same time (a near impossibility considering the various schemes used for addressing disk controllers). Also, it's questionable whether any machine has enough slots for all the different types of hardware required, and the BIOS would be quite long and involved.

Another way of moving files around which, while slower, is at least more practical, is to simply transmit the file from one computer to another via some sort of interface. This method has the advantage of not requiring the same disk system, in fact it doesn't require the same anything except the interface convention (i.e. RS-232, Centronics, Etc.) and that both machines have CP/M running on them. The connection between the two systems may be a simple interface cable or it may have a pair of modems and a telephone line between them, thus allowing remote transfer of files. The modem method is, of course, much slower since it is no problem at all to send files from one machine to another on an RS-232 cable at 9600 baud (some 32 times faster than most modems are capable of!) Still, it is sometimes impossible to place the computers physically side-by-side and modems may have to be used.

With transfers between machines using a hardwired cable, it isn't usually necessary to add a checksum to insure data integrity (it doesn't hurt, however), since interface reliability in the absence of a phone line should be quite good. However the case of transfer via modems is much different. Telephone line quality can vary from good to atrocious (more often the latter than the former) and some means must be adopted to make sure that what arrives at the receiving end is the same information that started out at the sending end. This is where the checksum comes in. For each block of data sent the sum of the bytes transmitted is calculated and at the end of transmission of the block, this "checksum" is also transmitted. At the receiving end the computer is adding up the values of the bytes received one by one as they come in. When the final data byte has been received, the checksum is transmitted and examined by the receiving machine. It then compares the checksum received with the one it has been calculating and, if these are the same, it is assumed that the block has been transferred correctly.

While an in-depth explanation of error-detecting and error-correcting codes is not appropriate here, suffice it to say that the probability that there will be two errors in transmission which cause equal and opposite results is so minute as to not be worth worrying about. In a case where something like national security is involved, more elaborate error-detecting and correcting codes are available to cover this possibility but for our use they are not needed. In addition they would slow down what is already a painfully slow method of moving data between computers.

There are basically two ways that data can be represented during transmission from one computer to another. The first of these is simple ASCII coding. This works fine for text files but runs into a bit of a snag for machine-language or executable programs. ASCII is defined as a 7-bit code with a parity bit added as the 8th bit. However, binary files may have any combination of bit patterns making up the byte and can't afford to waste the 8th bit as a parity bit. In the case of some existing file transfer programs, a binary file must first be converted into a form that is representable by ASCII characters (a HEX file) before transmission. It is then transmitted and reconverted into a binary file at the receiving end. While this works, it forces the transmission of two bytes of data for each byte of binary information that must be transmitted, thus in effect cutting the transmission speed in half. Using this method would limit the effective data transfer rate on a modem to around 15 bytes/second. As I mentioned above, even 30 bytes/second is irritatingly slow especially when transferring long programs, not to mention the expense if this is happening long distance. The alternative to this, which I am using here, is to make sure the serial port used is configured for 8-bit words and no parity bit. Most any serial port can be configured this way with a little snooping in the user's manual. In fact I have found that roost hardware manufacturers use this is the default configuration for their serial data ports. With this accomplished, a binary byte can be transmitted as is, and any error-detecting can be left to the checksum rather than the parity bit.

The programs presented here are designed to work with each other in moving files between CP/M machines. The basic method of transfer is to have the receiving machine in control of the situation. The transmitting machine waits until the receiving machine is ready before sending anything. This allows for the case where the receiving machine may have a slow disk system and a large file is being transferred that can't be buffered in memory in its entirety. The receiving machine must pause to dump its buffer to the disk, and during this period the transmitting machine must wait to insure that it will not be transmitting when the receiving machine is busy with its disk work. Upon dumping the buffer, the receiving machine can signal that it is ready to begin accepting data again and the transmitting machine can start sending at that time.

An additional feature present is a certain amount of error-correcting. The term "correcting" is a bit of a misnomer because it is accomplished here by simply retransmitting a garbled record until it is received correctly. There is a two-way communication between the machines (full duplex) so that they can decide when a record has been correctly received. The number of retries for a badly-transmitted record is 4 here but can be altered to any other value to suit the user's purpose. Aborting a transfer is also possible since the program polls the console device using a BDOS call, and if the operator types a control-C, the transfer is terminated and a message so stating is printed on the screen. As each record is transmitted and received, a message is printed on the screen so that the operator can monitor the process. If a record must be transmitted, the word "again" is appended to the message. When the entire file has been finally transferred, the message "Transfer Complete" is printed and the program reboots.

The procedure to follow in using these programs, once they have been entered into the machine, is quite simple. First of all, the user must identify the port numbers and input and output flag bits for the serial port concerned. This information is almost always available as part of the user documentation for the system. These values must then be inserted into the source listing for the programs and the programs assembled.

If the connection is a hardwired cable it must connect the serial interface on the first machine to the serial interface on the second. In most cases a cable may be needed that reverses pins 2 and 3 of the DB25 connector on one end since it will probably be the case that both machines are wired to connect directly to printers and will use pin #2 for received data.

If the connection is being made via a phone line and modems, each machine should have a cable suitable for connecting it to a modem. Most computers are wired as DCE (Data Communications Equipment, i.e. they emulate a modem) and will probably need a crossover cable to connect to an actual modem, but this is not universal so consult your user manual on this.

Since the receiving program is in control of the process, the transmitting computer should begin first with the operator typing 'TX (drive:)filename(.filetype)' where the items in parentheses, the drive and filetype, are optional. The quotes are not entered. If the filename is omitted, an error message results and the program reboots. After waiting a few seconds for the computer to open the file and load the buffer, the receiving operator types 'RX (drive:)filename(.filetype)'. His computer then erases any old file by that name, opens a new file and signals the transmitting computer to begin. At this point the computers may be left alone until the process is complete barring any unrecoverable error conditions.

In practice, even though the receiving computer is calling the shots, I have found that it doesn't seem to matter who actually types his carriage return first, the sending or the receiving party. The handshake link is established satisfactorily either way and the transfer proceeds normally. So don't worry too much about counting to five or whatever before hitting return.

In order to keep the complexity of the programs down, it was necessary to limit the transfer to a single file for each execution of the program. This is not really a problem in the case of long files since one would want to check on the progress of the transfer periodically and re-executing the program for the next long file wouldn't be a burden. In the case of a large number of small files, I have found that the best procedure to accomplish this is the SUBMIT utility of CP/M. Making up a submit file such as:

	TX PROG1.TY1
	TX PROG2.TY2
	TX PROG3.TY3
	TX PROG4.TY4

and calling it SEND.SUB allows the whole thing to operate by typing in SUBMIT SEND. The SUBMIT program then executes each line in turn until all files have been transferred. The receiving end computer must of course have a similar file but with the letters RX in place of TX on each line. Our procedure here is to first send the submit file with a manual command, then have the receiving end operator edit it and replace the TX's with RX's. This helps insure that the order of the programs being transferred will be the same on both ends. The receiving computer operator can then type SUBMIT RECEIVE (assuming he has named the file RECEIVE.SUB). We have used this procedure to transfer series of files that take an hour or more via modems and, except for checking the machine every ten minutes or so, both operators can work on something else during the transfer process.

These programs offer the hacker a good way to move files between CP/M machines, even with toatlly different disk systems. The only requirement is that each have a serial port. Transfer can be made with either a direct interface cable or a pair of modems. (Why is it I always want to make the plural of modems moda?) The programs are very tolerant of timing and contain the facility for retransmitting records containing transmission errors. We have been using them in this area for quite some time now and found them to be very satisfactory for our purposes. The listings are included here for those who want to key them in. If you would rather avoid the effort and errors involved with keyboarding the data, send $15 to The Computer Hacker for an 8-inch single-density floppy disk containing a CP/M copy of the source files.