Simtel MSDOS - Coast to Coast

home *** CD-ROM | disk | FTP | other *** search

/ Simtel MSDOS - Coast to Coast / simteldosarchivecoasttocoast2.iso / zmodem / mpmod154.zip / MPMODEM.DOC < prev next >

Wrap

Text File | 1993-08-31 | 77KB | 1,771 lines

MPModem v1.54 Implements Xmodem, Ymodem & Zmodem all in one package. (C) Copyright 1992,1993 All rights Reserved. Mark Jose This manual is Copyright (C) 1992, 1993, M. Jose. MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 1 Table of Contents ----------------- 1.0 Terms and Conditions of use ................................ 2 1.1 Disclaimer ................................................. 3 1.2 License agreement .......................................... 3 2.0 MPModem: What does it do? .................................. 4 2.1 The MPModem Screen ......................................... 5 3.0 What equipment do I need? .................................. 8 3.1 Configuring MPModem with MPConfig .......................... 8 3.1.1 File Transfer Options Screen ............................ 9 3.1.2 General Setup Options Screen ............................ 15 3.1.3 Screen & Colours Setup .................................. 17 3.1.4 Save Configuration ...................................... 17 4.0 Running MPModem from DOS ................................... 18 4.0.1 Registered and BBS Users ................................ 22 5.0 File Formats ............................................... 24 5.0.1 Input File .............................................. 24 5.0.2 Log file format ......................................... 24 5.0.3 Report file format ...................................... 25 6.0 Future Enhancements ........................................ 26 7.0 Messages ................................................... 27 7.0.1 System Messages ......................................... 27 7.0.2 Report File Messages .................................... 36 8.0 Acknowledgements ........................................... 38 9.0 Errors or Omissions ........................................ 39 9.1 Other things ............................................... 39 MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 2 1.0 Terms and Conditions of Use. --------------------------------- This program is freeware and as such the author retains full copyright over the contents of this file and all files written by the author. The author encourages you to distribute this program to any person or persons you wish so long as the contents thereof are unaltered in any way other than the form of archiver or compressor used. The author supports the use of the LHA group of compressors and archivers. See "License agreement" for more details and specifics. MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 3 1.1 Disclaimer --------------- This product is provided to you "as is". There is no warranty either expressed or implied applicable to this program or any other utility or program produced by the author. Use of this program is at your own risk and as such the author is not liable for any damages or loss of profits resulting either directly or indirectly from your ability to correctly or incorrectly use the said products. The author makes no warranty that this program and all associated programs are fit for any particular purpose. Any implied warranty of merchantability is expressely and specifically denied. By using this program, its associated programs and documentation you agree to the above conditions as outlined in sections 1.0 and 1.1 respectively. 1.2 License agreement ---------------------- You are granted a license to use this product for whatever reason you see fit. Under no circumstances do you own this product. Although it is free to you, it is NOT Public Domain - it is copyrighted by Mark Jose and shall remain so. You may distribute this program in unmodified form which includes all programs, documentation, data and other files. You may not include the product with any other product for any reason whatsoever and you may not charge or elicit payment of any kind for the copying or transfer of this program for other people to evaluate other than to recoup the costs of the media that contains this product. There are exclusions to this: If you first contact me, I MAY allow you to include this program with other packages like CD-ROM software collections and so on. In which case, terms can be negotiated. All Bulletin Board operators may allow the downloading of this product providing the Bulletin Board is not engaged in trading for profit and/or repackaging software in any form other than the original form of this product and all its accompanying articles and products and is not charging users of their Bulletin Boards a specific fee to download this product. If you are uncertain of your obligation under the law either desist from using this product or obtain legal opinion. MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 4 2.0 MPModem: What does it do? ------------------------------ MPModem implements 3 main protocols, these being Xmodem, Ymodem and Zmodem. It also implements a further derivative of Xmodem, Xmodem with 1024 byte blocks (the normal is 128 bytes) as well as Ymodem-G, a full streaming non-error-correcting protocol derived from Ymodem. The implementation of Ymodem is not just simply Xmodem with 1k (1024 byte) blocks and a filename header but rather it is the "real" Ymodem which can take varying sized (128/1024 byte) blocks, transfer files without padding and preserves the file date and time. Zmodem is the evolution of X/Ymodem to a more flexible protocol. It has the ability to resume a previously aborted transfer and is very rigid when dealing with noisy lines (though not perfect). It also supports Turbo-style (Fast) file transfers. At present it supports RemoteAccess BBS and will in future support many more, especially Australian produced bulletin board programs. My implementation of Zmodem is the same as that of other authors of Zmodem with the major exception that it allows the transfer of files from systems like the Macintosh (tm), Apple (tm), Unix (tm), BSD (and its various connotations) without causing problems with filenames and MacBinary headers (when it is a MFS). This system is called "Filename Integration" and is copyrighted by me. MPModem uses fully buffered interrupt driven serial output and input for optimum throughput and is optimised to give you the very best in protocol handling. It uses a minimum of memory and will run quite well in less than 100k of memory (providing you don't use a large disk buffer). It is optimised to work well under Desqview (tm) and has built in facilities to change the method of screen writing (for the benefit of other less well behaved multi-taskers). MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 6 2.1 The MPModem Screen. ------------------------ ┌──────────────────────────────────────────────────────────────────┐ │ Zmodem Receive (1) │ ├──────────────────────────────────────────────────────────────────┤ │ Pathname: (2) │ │ Filename: (3) │ │ │ │ Check Type : CRC-16 (4) Blocks Expected: (11) │ │ Error Count : (5) Blocks Received: (12) │ │ Last Frame : (6) Approx. Cps : (13) │ │ │ │ Transfer Time: (7) Bytes Expected : (14) │ │ Elapsed Time : (8) Bytes Received : (15) │ │ │ │ Messages: │ │ Initializing file transfer. (9) │ (10)│(16)(17)(18)(19)(20)(21)(22)(23) (24) (25) (26)│ ├───┬───┬───┬───┬───┬───┬────┬────┬────┬────────────────────────┬──┤ │LOG│BIN│CAR│MOD│ │ │ │ │ │Space: 3241984 bytes│ 5│ ├───┴───┴───┴───┴───┴──┬┴────┴────┴────┴────────────────────────┴──┤ │Serial No. 0000000 (27)Reg. To: UNREGISTERED (28) │ ├────────────┬─────────┴─────────────────────────────┬─────────────┤ │ (29) │ MPModem (C) Copyright 1992, M. Jose │ 1.00 (30)│ └────────────┴───────────────────────────────────────┴─────────────┘ [Registered users will see a slightly different screen] (1) The type of transfer about to take place. (2) The "Pathname" is the path to the upload or download directory. (3) The "Filename" is the name of the file currently being received or sent. (4) "Check Type" is the type of block checking that is relevant to the particular transfer type you have selected. With Zmodem the type of checking is either CRC-16 or CRC-32. With Xmodem and or Ymodem the checking is either checksum or CRC-16. (5) "Error Count" is the total number of errors so far encountered while performing this file transfer. If Zmodem reaches about 14 errors it will abort. (6) "Last Frame" is only relevant to Zmodem. This basically displays the last packet type that was received by Zmodem. (7) This field will display "Transfer Time" if you are receiving/downloading a file and will display "Time Left" is you are sending/uploading a file. (8) "Elapsed Time" is the total amount of time so far taken to receive or send the file. (9) This field displays any error and system messages. MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 7 (10) Directly under the error and system messages field is the warning message area. Generally this is only used to show the filename that was transmitted before converting the filename to DOS format. (See the "-m" switch). (11) This field displays "Blocks Expected" when receiving/downloading files or "Blocks To Send" when sending/uploading files. This field is only used when sending with Xmodem or Ymodem and receiving files with Ymodem. (12) This field displays "Blocks Received" when receiving/downloading files or "Blocks Sent" when sending/uploading files. This field is used when sending or receiving using Xmodem or Ymodem protocols. (13) "Approx. Cps" is an approximate Characters Per Second rate when transferring files. Please note that because of internal buffering when tsending files, the CPS rate may seem too high for the baud rate selected. (14) This field displays either "Bytes Expected" when receiving/downloading files or "Bytes To Send" when sending/uploading files. When sending files with any protocol this will always contain the size of the file regardless of the protocol used. When receiving files, an amount will only be shown if you are using Ymodem or Zmodem. (15) This field displays either "Bytes Received" when receiving/downloading files or "Bytes Sent" when sending/uploading files. An amount of bytes will be shown as the file transfer progresses to show how far the file transfer has progressed. (16) If "LOG" appears in this frame then the current transfer is being logged to the file "MPMODEM.LOG". To enable this function, ensure that the "-l" switch is part of the command line. (See "-l" for more information). (17) If "BIN" appears this means that the current Zmodem (only) transfers is being transferred in binary mode. To override this (keeping in mind the ramifications of such action), you may specify the "-a" switch on the command line. (See "-a" for more information). (18) If "CAR" appears this means that the carrier is currently being monitored. This means that as soon as the carrier is found to have been lost the program will finish the transfer. To activate this option, select the "-c" command line switch. (See "-c" for more information). (19) If "MOD" is displayed this means that ALL incoming files are checked and modified to DOS standards. This is handy when transferring files from a Macintosh or other "strange" naming convention site. (See "-m" for more details). MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 8 (20) This box is blank. (21) If we are running in fast mode (some implementations call it Turbo) then it will contain the letter "F". (22) If "KILL" appears in this box while receiving a file then this means that if the transfer is aborted and the file not properly recieved then that file will be deleted. If it appears while sending then this indicates that after the successful completion of the transfer, this file will be deleted off your disk. (23) This is the current block or packet size of the transfer. With Xmodem it is always 128 (bytes), with Xmodem-1k it is always 1024, with Ymodem and Ymodem-G it can be 128 and/or 1024, and with Zmodem it can be from 32 to 1024 bytes. (24) Blank. (25) This is the current amount of free bytes left on the disk where the recieval of the file is going to. It is not perfectly accurate until the whole file has been received since it does not take into account the amount of disk space taken for directory entries etc. It is merely there to give you an indication of disk space. If you use a multi-tasker then the figure may be wrong until the next file is started and a physical read of disk space takes place. (26) This is the current time out value in seconds. This time dictates how long the transmitter or receiver routines will wait before giving up and issuing an error message. (27) This is the serial/registration number of this version of the program. Nothing will appear in here UNTIL you register your version of the program. (28) This field is allocated for your name when you register your copy of this program. If you have not registered, the field will flash with the word "UNREGISTERED" which is a subtle reminder for you to register your version. Please do so. (29) This is the version number of the remote user. It is generally not used by other Zmodem programs other than RZ/SZ on Unix (tm) machines. (30) This is the version number of the local user. When you are registered and you have a problem, remember to cite your version number when seeking assistance. MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 9 3.0 What equipment do I need? ------------------------------ You need the bare minimum configuration of PC equipment which comprises a PC, PC/XT, PC/AT, PS2 and so on up the scale. You require at least 256k of memory or much more if you are running this from a BBS. As well you will require a COM1: or COM2: serial output which has an 8250, 16450 or 16550 chip. 3.1 Configuring MPModem with MPConfig -------------------------------------- In order to streamline the usage of MPModem, there is a facility available to preconfigure MPModem using a program called MPConfig. This program allows you set most "options" and thus never have to change them during the normal course of running the program. Open invoking MPConfig, you are presented with a screen: ╔═══╡ Configuration Menu ╞═══╗ ║ ║ ║ File Transfer Options ║ ║ General Setup Options ║ ║ Screen & Colours Setup ║ ║ Save Configuration ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ╠════════════════════════════╣ ║ MPModem ║ ║ Copyright (C) 1992, v1.1 ║ ║ M. Jose ║ ╚════════════════════════════╝ This is the "master menu". Here you select the option you would like by pressing the Up or Down arrow keys. Once the menu bar (it will highlight the text) is over the required option, press the [Enter] key to enter that sub menu. MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 10 3.1.1 File Transfer Options Screen ----------------------------------- The following is the screen which is displayed when you select the "File Transfer Options" off the master menu: ╔════════════════════════════╡File Transfer Options╞═════════════════╗ ║ ║ ║ Always monitor Carrier during transfers?............. N ║ ║ Delete a failed transfer? (Receiving).............. N ║ ║ Allow remote to execute programs/commands?........... N ║ ║ Use XON/XOFF software flow control?.................. N ║ ║ Use CTS/RTS hardware flow control?................... N ║ ║ Delete file after transfer? (Sending)............... N ║ ║ Always log file transfers?........................... Y ║ ║ Modify filenames when receiving files?............... N ║ ║ Generate timeout values according to Baud rates?..... Y ║ ║ Use BIOS when writing to the screen?................. Y ║ ║ Force the sender to resume if necessary?............. N ║ ║ Force the sender to resume with CRC check?........... N ║ ║ Run this program from a BBS?......................... N ║ ║ Allow creation of a unique name? (BBS only).......... N ║ ║ Blank................................................ N ║ ║ Always Escape all control characters? (Zmodem only).. N ║ ║ Use current Comm. port settings for Baud rate?....... N ║ ║ Always scan for duplicate files. (BBS Receive only).. N ║ ╟────────────────────────────────────────────────────────────────────╢ ║Esc: Exit, : Move MPModem Configuration (C) Copy║ ╚════════════════════════════════════════════════════════════════════╝ Now follows an explanation of all the configuration questions. Always Monitor Carrier during transfers? Selecting "Y" will result in MPModem quitting the current transfer if it detects the loss of carrier. For those modems that do not force carrier high, do not use this switch but rely on the "timing" capabilities of the program to know when a connection is lost. That is, continual timeouts by X/Y/Zmodem will cause it to abort. (See Timeout for more details). If you only want to occasionally monitor carrier, then do not annswer Y here but specify "-c" on the command line when you want to monitor carrier. Delete a failed transfer? (Receiving) If you answer "Y" to this question, MPModem will DELETE any failed transfer. This option is especially useful for BBS operators who do not want their disk crowded with partially received files. The default is 'N'. MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 11 Allow remote to execute programs/commands? Answering "Y" will allow Zmodem to receive commands from the receiver requesting that certain commands be done. For example, MPModem can be made to execute another program or even run a batch file. It can be made to execute a command and then return back to the program or it can be made to overwrite the current program in memory with another program specified by the remote. This is a potentially powerful and dangerous option and should only be activated when you have 100% confidence in the remote user. Generally only users on Unix machines will have access to this ability. It executes the unix command of "SH" for shell. If you want the equivalent for DOS then check your local BBS for one and rename it as "SH" and place it in your MpModem directory. The default is 'N'. (This is not available to unregistered users) Use XON/XOFF software flow control? When a protocol is being "flooded" by characters, it is sometimes necessary to say to the other end "Hey! Wait for me". To perform this, we send an XOFF which tells the remote to stop sending data until we send the matching XON. If this is what you need and CTS/RTS flow control is not available then answer "Y" to this question. It is recommended that you ensure that your modem is set up to allow XON/XOFF flow control. This option only really serves a purpose if you are running under a multi-tasking system where all the CPU time cannot be allocated to one task for a continual enough time. Please Note: Because the Xmodem/Ymodem protocols do not handle XON/XOFF flow control, this ability will be disabled even if you have answered "Y". The only protocol XON/XOFF works with is Zmodem. It is NOT RECOMMENDED that you use this method of flow control. If flow control is needed and your modem can do flow control then using CTS/RTS flow control is the preferred method. The default is 'N'. MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 12 Use CTS/RTS hardware flow control? Answer "Y" here to use CTS/RTS flow control. Originally this type of control was designed for half-duplex modems where the change in signal would cause the modem to swap from being a receiver to being a transmitter. Now it is more commonly used with speed buffered modems (with say, a connect rate of 9600 and a DTE rate of 19200). To prevent the modem from skipping data, the modem's RTS pin's voltage is lowered to tell the local DTE that we must pause, until RTS is again asserted, before sending any more data. If you have speed buffering, MNP or LAP/M then make sure CTS/RTS flow control is enable on the modem and also through the program. The default is 'N'. Delete file after transfer? (Sending) Answering 'Y' will mean that after each successful SENDING of a file, that file will be deleted off your disk. This is especially handy for people who are sending one off files that are no longer needed on the host machine. The default is 'N'. Always log file transfers? It is suggested that you leave this as 'Y' (Log always on) as important information is placed in the log. For Sysops, it is MANDATORY in order for their supported board to work properly. The default is 'Y'. Modify filenames when receiving files? If you are always receiving files from a Macintosh source or you are a Sysop who thinks he may receive files from a Macintosh source, then answer 'Y' to this question. For example, a file transferred from a Macintosh (tm) machine may be called: Some Macpaint Pics.cpt with this switch active, the filename would be converted to "Some_Mac.cpt". Although this option is only really useful when transferring files from a Macintosh (R) system to DOS you should still answer "Y" here just in case you ever receive a file from a Macintosh user. Any non-standard MS/PC Dos format (even Unix and Amiga) will be converted to DOS format. The default is 'N'. MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 13 Generate timeout values according to Baud rates? Answering "Y" to this question will make MPModem calculate the value (in seconds) required for timeout handling according to the BPS rate (not the BAUD rate). Thus the faster the connection speed the shorter the timeout value. The absolute minimum timeout value is 5 seconds and the maximum is around 50 seconds for a 300 BPS connection. Use BIOS when writing to the screen? Answer "Y" to this if you are always running under a multi-tasking/ multi-window environment where "bleed-through" is not desirable. Although the screen writes are some degree slower if you answer "Y", it is better than "bleed-through" to the other screen if you answer "N". If running Desqview then you may use "Y" for direct screen writes as this program is very well behaved when used with Desqview and it will speed up screen writing. The default is 'N'. Force the sender to resume if necessary? This affects Zmodem file transfers only! This is the same as the "-x" switch. IF you are running a BBS then make sure that you answer 'N' to this question. To all other users, it is recommended that if you receive files from a Macintosh system where the filename is renamed that you also answer 'N'. The reason why is: Suppose you want to receive two files from a Macintosh system called "GeneralText.Word" (size 25067) bytes and another file called "GeneralTestAns.Word" (size 15460) bytes. With the "-m" switch specified the first filename will be renamed as "GENERALT.WOR". When you receive the second filename, it too will be renamed to "GENERALT.WOR". If you force the sender to resume, it will try to resume at 25067 bytes (the original size of "GeneralText.Word"). As you can see this is past the total file size of the incoming file "GeneralTestAns.Word". Improperly written Zmodem drivers will seize up at this and at the very least the first file "GeneralText.Word" will be truncated and overwritten. Generally, the author encourages ALL users to leave this switch as 'N' unless they are absolutely certain they realise the consequences of their actions. MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 14 Force the sender to resume with CRC check? This is the same as answering "Y" to "Force the sender to resume if necessary" (see above), however this causes Zmodem to first do a CRC check of the file (or the part thereof) to ensure that the file is the correct one to resume with. Do NOT use this switch if you are running MPModem under a BBS. [A bug in its implementation with some protocols has led to the] [withdrawal of this facility from this version. A fix will be ] [released soon, my apologies. MJ. ] Run this program from a BBS? This switch is the same as the "-!" switch. Answer 'Y' to this question if and only if you are running this program from a BBS such as RemoteAccess. The default is 'N'. Allow creation of a unique name? (BBS only) When receiving files it is sometimes necessary to create a unique filename if the incoming file has the same name as an existing file. For example, suppose we had a file called "frednurk.zip". If the incoming file is "frednurk.zip" but is a different size than the "frednurk.zip" we have on our system then the incoming file is received as "frednurk.zi1". Under normal circumstances this is not desirable when running under a BBS as this would allow people to upload a file that is already in existance. The default is "N". MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 15 Escape all control characters? (Zmodem only) If you are to use Zmodem to send to a remote site through a network that does not accept the full IBM character set of 0 to 255 decimal, and thus only supports A-Z, a-z and characters like %$#@!*&^, then answer "Y" to this question. This will cause all control characters and extended ascii characters to be converted to a character acceptable by the network or computer you are sending to or receiving from. Using this method will cause the program to run slower as it has to encode such characters which adds 50% to the overhead of the program. Use current Comm. port settings for Baud rate? Answer "Y" to this if you are running MPModem under a BBS or some program that does not report the actual connect rate. Some BBS (like RemoteAccess) report only the carrier speed which may differ if speed buffering for MNP or LAP/M is active. For example, you may connect with a CARRIER speed of 9600 but a CONNECT speed of 19200. MPModem requires the CONNECT speed rather than the CARRIER speed. If you are having trouble running MPModem - when you select it you get garbage appear on the screen - then answering "Y" to this option will rectify the problem (if it has to do with invalid BAUD rates!) Always scan for duplicate files. (BBS Receive only). When this option is set to Y, MPModem will scan your FILES.RA (it only applies for RemoteAccess at the moment), and try to ascertain whether the file that is about to be received (uploaded by the user) is not already on the file base. This option is necessary for total file security on a BBS but may disadvantage some users whereby the incoming file is from a non-DOS compatible machine and is modified to the standard DOS filename. Likewise a BBS that stores files on its system from another system (Amiga or Mac), then the DOS filenames will not (generally) correspond to the "true" filename. If you are running such a board, then I would suggest that you keep this option set to "N". It will also speed up the time Zmodem takes to start a file transfer. This option does not apply to Ymodem, yet. MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 16 3.1.2 General Setup Options Screen ----------------------------------- The following is the screen which is displayed when you select the "General Setup Options" off the master menu: ╔════════════════════════════╡General Setup Options╞═════════════════╗ ║ ║ ║ Enter size of Disk I/O Buffer. (1 to 20k) 1 ║ ║ If running from a BBS, enter port number. (1 or 2) 0 ║ ║ Wait for user to ACK. (32 to 1024 bytes) 0 ║ ║ Use sub-packets. (24 to 1024 bytes) 0 ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ╟────────────────────────────────────────────────────────────────────╢ ║Esc: Exit, : Move MPModem Configuration (C) Copy║ ╚════════════════════════════════════════════════════════════════════╝ Enter size of Disk I/O Buffer. (1 to 20k) This allows you to specify the Disk Read/Write buffer and is the equivalent to the "-f buffer_size" switch. Specifying a buffer of around 2 to 4 will decrease the amount of disk writes. When running a multi-tasking and/or multi-line BBS and you have plenty of memory to spare set the buffer at anything from 10 upwards. If running from a BBS, enter port number. (1 or 2) This is the same as specifying "-p{portno}" on the command line. If you enter a port in here, this port will ALWAYS be used regardless of what your communication or BBS program passes to MPModem. Use this wisely. MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 17 Wait for user to ACK. (32 to 1024 bytes) Entering a number in here (from 32 to 1024) will cause Zmodem to work just like an ACK-type protocol such as Xmodem. What this does is cause Zmodem to create "frames" of the size you specify to be sent before an ACK is required to be sent by the remote system. For example, 512 will result in an ACK being sent after every 512 bytes. If you do not wish to run Zmodem as an ACKed protocol, and thus as a full streaming protocol, then do not enter a number in here. Use sub-packets. (24 to 1024 bytes) Entering a number (from 24 to 1024) in here will cause Zmodem to use sub-packets of a certain length. For example, 256 will result in sub-packets of 256 bytes being sent. Specifying a number is especially useful if you expect the transfers to take place under noisy conditions where error-recovery is optimised by sending smaller packets. The tradeoff, however, is a higher overhead as smaller packets require more data to be "wrapped around them" such as CRC check bytes and header information. MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 18 3.1.3 Screen & Colours Setup ----------------------------- This screen allows you to change the colours of the various screens used by MPmodem and its associated programs. If you don't have a colour monitor then this option is superfluous to your needs. ╔════════════════════════════╡Screen & Colours Setup╞════════════════╗ ║ ║ ║ ║ ║ Screen Background colour ║ ║ Screen Borders ║ ║ Field Names ║ ║ Text & Data Info. ║ ║ Status line ║ ║ Message colour ║ ║ Warning colour ║ ║ Menu Bar colour ║ ║ Menu text colour ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ╟────────────────────────────────────────────────────────────────────╢ ║Esc: Exit, : Move MPModem Configuration (C) Copy║ ╚════════════════════════════════════════════════════════════════════╝ 3.1.4 Save Configuration ------------------------- Moving to this option and pressing [Enter] will cause the current settings to be saved to a file called "MPMODEM.CFG". Ensure that before you quit (unless you do not want to save your changes) that you select this option. MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 19 4.0 Running MPModem from DOS ----------------------------- MPModem runs by specifying switches on the command line. Some of the command line switches are optional but a few are mandatory such as the Port, the Baud rate and the transfer type. Below are detailed a list of the switches/options you may use with MPModem: Switch/ Option Description ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -@ This causes Ymodem or Zmodem to obtain the list of filenames to send to the remote from a file. To use this you must follow this switch with the filename to use. E.g -@ input.fil Note that there must be a space after the "-@" and then the filename. For more details of the make up of the input file to read from, see "Input File". This switch is optional. -a When using Zmodem this forces the transfers to be made -A in Ascii (raw text) mode. Thus transfers from Unix or Macintosh sites will result in the LF converted to a CR/LF combination compatible with DOS. Using this switch with a Binary file will result in unmentionable things happening to the file! This switch is optional. -b This sets the baud rate. Immediately following the "-b" -B must be the baud rate. Currently, the baud rates supported are: 300, 600, 1200, 4800, 9600, 19200, 38400, 57600, 115200. For example, -b9600 will specify that the transfer is to take place at 9600 baud. If you are running a v.42bis/LAPM/MNP modem at 2400 baud or greater then it is imperative that the "CONNECT" speed is passed to MPModem, not the CARRIER speed. For example, connecting LAPM at 38400 must result in "-b38400" being passed to this program. (Generally speeds in excess of 19200 require a fast XT or an AT and greater). This switch is NOT optional. MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 20 -f Run Zmodem in fast mode. This greatly depends on the -F remote's ability to run Zmodem in non-standard mode. Programs such as PCZ work fine. DSZ does in some versions. This switch is entirely optional. MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 21 -p Defines the port number. MPModem can operate from ports -P 1 and 2. (See "Future Enhancements" for more details.) You must specify the port number (1 or 2) directly after the switch, eg. -p1 will make MPModem run from Port 1 of your machine (the standard port). -r Causes MPModem to go into receive mode. You may specify -R 5 individual protocols to use: -rx Receive Xmodem (128 byte packets) -ry Receive Ymodem -rz Receive Zmodem -rg Receive Ymodem-G -rk Receive Xmodem (1024 byte packets) You MUST specify at least one of these commands on any command line if you are receiving files. -s Causes MPModem to go into send mode. You may specify -S 5 individual protocols to use: -rx Send Xmodem (128 byte packets) -ry Send Ymodem -rz Send Zmodem -rg Send Ymodem-G -rk Send Xmodem (1024 byte packets) You MUST specify at least one of these commands on any command line if you are sending files. -t This switch is used only by BBS operators. It enables -T sysops to see what time is left for the user while running MPModem. The sysop will specify this in his configuration setup for running MPModem as an external protocol. -u Use this switch ONLY when you are running MPModem from -U a BBS. Follow this switch with whatever option your BBS has for putting the Usernumber on the command line of an external protocol. For example, RemoteAccess allows you to put a user's number on the command line by entering the following: -U*R Thus MPModem can use this information to report on any suspicious activity by the user. MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 22 -v This switch enables BBS operators only to specify the -V user's name on the command line. Generally if you want to use the entire name (first name and full name) then you must join the two names with an underscore (_). For example, running RemoteAccess you may specify it as: -v*F_*L which will join the user's first name with his last name by an underscore. -w Sound a "warble" when the program has finished doing -W its transfers. This facility is only available to registered users. -y Put Zmodem into resume mode. If you have not specified -Y that you ALWAYS want Zmodem to try to resume a transfer (this is done via the configuration program) then specify this switch will allow you to resume files for the duration of this session only. This switch is preferable to the option in the configuration file because the configuration file option will ALWAYS force Zmodem to resume, even when you may not want it to. MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 23 4.0.1 Registered and BBS Users ------------------------------- If you are a registered user or a BBS operator, then the screen will differ from what unregistered users will see. At the very bottom of the screen will appear a rectangle which will display the following information: Registered User BBS User --------------------------------------------------------------- BBS Name connected to. Current online user. Baud rate (Connect rate) Baud rate (Connect rate) Time online so far Time remaining Registered User ~~~~~~~~~~~~~~~ If you can pass to the program from your calling communications program like Telemate, Procomm or Telix the following information, the it will appear on the screen: -vBBSName -tTimeOnline "BBSName" is the name of the BBS you are currently calling. "TimeOnline" is the current amount of time you have been online. This information is ideal for allowing you to keep accurate track of where you are logged in and how much time you have spent on that board. Telix is able to pass (via a script - an example is enclosed) the name of the system you are connected to but not the time. It is therefore necessary to pass a value of 0, as in "-t0". The time value MUST be given in minutes, not seconds or hours. Other communication program may be able to do this and if so good, but Telix is my program of choice so I have not had time to experiment. If you write a script, then email it to me (DO NOT INCLUDE IT IN THE BUNDLE OF SOFTWARE CONTAINING MY PROGRAMS!) or send it to me via the Internet to speednut@werple.apana.org.au. Telemate (v3.10) allows you to create scripts but does not allow you to link these scripts to the receive/send menu. Consequently you can only use batch files to execute additional protocols. You can, however, directly execute the scripts (.SCR) included with this package by typeing ALT-S and selecting the relevant script. MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 24 BBS User ~~~~~~~~ To aid in the better monitoring of who is using your Board, I have included the additional status line. This line will display the current user online, the baud rate he connected at and the time remaining (in minutes). This should greatly assist BBS operators. You must be a registered user or Sysop in order to use this facility. MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 25 5.0 File Formats ----------------- 5.0.1 Input File ----------------- The format of the input file is quite simple. It must be in ASCII and each line must be less than 80 characters in length. A line is just plain text with a CR/LF combination at the end. An example of what an input file would look like is detailed below: c:\programs\hold\pibterm3.lzh mpmodem.exe c:\games\canasta.lzh There is no limit to how many files can appear in the file, it really only depends on how long you have to send all the files to the remote end. 5.0.2 Log file format ---------------------- The log file is made up of pure ASCII (decimal 32 to 127 inclusive) and thus can be read by any program or editor. The following is an example of the MPMODEM.LOG file: 21-12-91 00:36:38 Zmodem Download 21-12-91 00:36:38 Remote filename: Planets Movie.cpt 21-12-91 00:54:59 Received: Planets_.cpt 21-12-91 00:54:59 Bytes: 207534 21-12-91 00:54:59 CPS: 1780 21-12-91 01:01:20 Zmodem Upload 21-12-91 01:03:24 Transmitted: QUICKTME.CPT 21-12-91 01:03:24 Bytes: 765010 21-12-91 01:03:24 CPS: 1970 Each line of the log file begins with the date in DD-MM-YY format (there are no spaces before the date). Next follows two spaces then the time in the format of HH:MM:SS in 24 hour notation so that 22:10:12 is 10:10:12pm. A further two spaces follow and then appears the type of download or upload, either "Transmitted:" or "Received:" , the number of bytes received and the CPS rate. MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 26 5.0.3 Report file format ------------------------- The report file is a pure ASCII file similar in appearance to the standard MPModem log file called "MPMODEM.LOG". The following is an example of what part of this file may look like: 21-12-91 00:36:38 25 has received all of file MPMODEM.EXE 21-12-91 00:36:38 25 has asked me to execute commands The "25" above refers to the user's number, and will only be displayed if you specify "-u" or "-U" on the command line followed by the BBS's code for a user number (see "-u" switch). The report file is used to report on strange occurrences during a file transfer. Some users have been known to abort the receipt of files just after the last bytes have been received and just before the End Of File packet has been sent. This then makes the BBS think that the file was not sent and thus this user's download amount is not adjusted. So, if a Sysop browses through this file he will immediately ascertain which users should be barred from using the file system or whatever. MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 27 5.0 Future Enhancements ------------------------ MPModem is by no means complete and will be continually updated to ensure registered users are able to use the most modern aspects of the protocols that make up the MPModem product. Some of the future enhancements are: * Ability to handle more than ports 1 and 2. Initially support will only be given to the additional ports numbered 3 and 4 but eventually ports 5 to 8 will also be included. * Extensions to Xmodem to allow it to send/receive in streaming mode (commonly called Xmodem-G or Xmodem-1k-G). It should be noted that Xmodem and Ymodem have reached their limit for expansion at the present time and thus the Zmodem transfer protocol will be the one that will be the focus of future enhancements. +-------------------------------------------------------+ | Please also note that due to my own time constraints, | | it may be a long time before the above is done. That | | is the main reason why I have made this software | | FREEWARE - I simply can't justify asking people for | | money without properly supporting the product. | +-------------------------------------------------------+ MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 28 7.0 Messages ------------- 7.0.1 System Messages ---------------------- Detailed below are all the major system messages that occur when using the MPModem product. Some are general messages or notices but most are error messages. Bad data CRC. While receiving data in either CRC 16 or 32 bit mode, MPModem the final CRC checking values did not agree with those sent by the sender. This can indicate two things, a very noisy line which is continually subjected to noise bursts or a badly designed sending program which may be experiencing transmitter overruns. If the problem always persists on the same connection, it may point to a software error in the sender's software otherwise it may just be a bad exchange or telephone line. Perhaps you should hang up and call back - after all Zmodem can resume transfers. Bad data subpacket. You are experiencing major problems where data is becoming grabled by either a lousy telecommunications line. Try hanging up and calling again. Maybe even cleans the contacts on the telephone socket and plug - it sometimes help. (Use a 600 grade sandpaper or better still Emery paper). Bad position. The current packet (just received) is not the next packet we wanted to receive so we will tell the remote and he SHOULD send us the correct packet. Too many of these errors will result in the "Too much garbage. I give up!" message appearing. See that error message for more details. Carrier Lost. When you specify the switch "-c" on the command line, MPModem will constantly monitor the carrier. If it drops out, it will close all open files and tidy up memory prior to exiting to DOS or returning back to the BBS. It causes the program to exit with a DOS errorlevel of 4. Data subpacket too long. Too much data has been received for this packet. Again, this points to a noisy line or faulty contacts. Perhaps someone just picked up the other extension and interfered with your call. Yell at them if that's the case! MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 29 Data TIMEOUT. While receiving data from the sender, MPModem got tired of waiting. This can point to a slow remote system or a lazy network. Firstly investigate the possibility that the remote is slow before sticking your finger at the remote's network; It's harder to diagnose! Error: Carrier Lost. Zmodem has encountered a loss of carrier. This message will only appear when you specify the "-c" switch on the command line. Error: Garbage in header. See "Garbage count exceeded (Header)". Error: Received a garbled packet. Zmodem has received a data packet (part of the actual file transfer) that is garbage. It will discard this file as possibly corrupt. Error: Receiving ZCOMPL. Zmodem has continually received ZCOMPL (Zmodem has finished the file transfer) out of sequence. It may indicate that the remote is not ready for the files. Error: Remote Cancelled! Zmodem has received a cancel sequence by the remote and is now also ending the file transfer. Error: Strange characters received! Zmodem has encountered some irrecoverable error or errors when receiving a file. The transfer is obviously becoming far too "mutilated" by the telephone or network system. Error: Timeout. A timeout has been received. Please see "Timeout" for more details. MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 30 Error: Too many CRC errors! While Zmodem is receiving the file it has encountered too many CRC errors to be considered safe to continue the file transfer. If this continues to occur then email me and I may put a switch in so that you can specify the number of times it will allow for CRC errors during the file transfer. Currently it is about 15. Error: Too much garbage. I give up! Zmodem has given up trying to receive the file because it keeps receiving data packets with a different file position to that of the current file position. This may indicate that the sender is no longer receiving information. Error: Trying for ZCMD. Zmodem has given up trying to respond to the request for some action (command) to be taken by the remote program. This version of Zmodem can execute a command (such as another program) and then return back to Zmodem or it can execute a program that replaces Zmodem in memory. While trying to do one of these things, no response was received by the remote program. Error: Trying for ZFILE. Zmodem has given up trying to receive the file header. End of story and end of transfer. It is possible the remote end has dropped out or has failed to load their Zmodem program. Error: Trying for ZSINIT. Zmodem has given up trying to send an initialization sequence to the remote program. It is possible the remote end has dropped out or has failed to load their Zmodem program. Existing file cannot be overwritten. This indicates that the sending program is trying to send a file that is on your system as either Read-Only, Hidden or System. This could indicate that the remote is trying to upload a copy of the the system files or other types of protected file. If it is one of the system files, then maybe it was an attempt at sabotage!?! At any rate, the attempt has failed and that file will be skipped. MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 31 File positioning error. While trying to move the disk pointer to another location within the file, an error was encountered and consequently the program could not reposition within a file. Generally this is a SERIOUS error as it indicates a problem in either the FAT tables or a problem with the actual media (hard or floppy disk). File transfer failed. Because of some reason the file transfer has failed. If you are concerned that file transfers are continually failing then read the documentation again and perhaps watch the transfer to see just what type of error messages appear during the file transfer. Garbage count exceeded (Header). While trying to receive a header packet, Zmodem has encountered too many errors. These errors are possibly due to a noisy line or indeed could be caused by a faulty modem or modem cable. Check that no earthing is occurring with the cable. Got bad Zmodem escape sequence. Zmodem "escapes" certain codes so that they aren't confused with other possible codes like XON/XOFF software flow control bytes. If Zmodem encounters a bad "escape sequence" that doesn't make sense to it, it will produce this error. Again this points more to a noisy or ineffective line than anything else. Interruption detected! Trouble? Zmodem has received an interruption (some bytes from the remote - possibly a Cancel or Reposition command) and will attempt to rectify the problem. This problem can be caused by improperly designed transmitter hardware or software and can point to transmitter overruns. If this continually occurs and you are a registered user then contact me and I will endeavour to help you. Please site the type of chip you have (8250, 16450 or 16550) and any details you may have. Invalid block number. (?? tries) Xmodem, Xmodem-1k, Ymodem, Ymodem-G has continually tried to receive the next block number but each time it is invalid. The "??" is replaced by the number of attempts the program has made to try to obtain the correct block. MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 32 Invalid chksum/crc. (?? tries) Xmodem, Xmodem-1k, Ymodem, Ymodem-G has received an invalid checksum or CRC value. The "??" is replaced by the number of times we have received this invalid checksum or CRC value. If you are running Xmodem with checksum, you should consider changing/forcing the remote to run under CRC because checksum checking of a packet WILL NOT catch all errors and thus you could end up receiving a file that is corrupted! Invalid Binary Header CRC. This means that a corruption has occurred when receiving a header record in Zmodem. Generally it indicates a poor line. If it persists it could point to bad software design by the remote sending program. Invalid header received. (?? tries) Xmodem, Xmodem-1k, Ymodem, Ymodem-G has continually tried to receive a header from the remote sender. The "??" is substituted with the number of tries so far. Hang up and try again if it persists. Invalid Hex Header CRC The hex header (used when initiating file transfers) has encountered a CRC error in the header. This is due to line noise corrupting the individual bits in a file transfer. If you encounter too many of these errors you would be wise to hang up or abort the transfer and start again. Invalid response (??) When the sender (Xmodem, Xmodem-1k and Ymodem) have finished sending a block of information, they expect to receive a certain character from the receiver telling them what they should do next. When this message is returned it indicates that the program has recieved an invalid character. When the message is displayed, the "??" is replaced with the hexadecimal value of the character received. It means that some spurious character has been received. If it continues, the program will eventually abort. MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 33 Local abort. You have pressed the "Esc" (Escape) key. No files to send! When you specify a wildcard (? or *) in a filename, eg fred*.*, and the program fails to find any files matching this description, it will announce that it has "no files to send" and will stop the transfer at this point. Remote cancelled! The remote sender or receiver has aborted or escaped out of the protocol and has told us to stop sending or receiving. Any file currently being transferred is close and the program ends. Remote filename: (This is NOT an ERROR message but rather a WARNING/NOTICE message). WHen you use the "-m" switch, MPModem will display the file it received from the remote prior to amending it so that it would fit within the parameters of a DOS file. For example, you may be receiving a file from a Macintosh system called: Some Macpaint Pics.cpt MPModem will convert this filename and display it as "Some_Mac.cpt". MPModem will then display (as a notice): "Remote filename: Some Macpaint Pics.cpt" Remote refused file! Zmodem tried to send a file to the remote but for some reason the file was rejected. Zmodem will endeavour to send the next file (if there is one) or else it will finish the transfer at this point. Repositioning. This tells you that the protocol is undergoing an error recovery by stepping backwards into the file to replace data already sent and was corrupt with data that is correct. In X/Ymodem this involves going backwards in the file by the amount of the current blocksize (128 or 1024 bytes) and with Zmodem it can mean going back to anywhere in the file. The position of where the program is re-starting the transfer from is displayed to the left of this message. MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 34 Sending data header. This is not an error message but rather it indicates that we are about to start sending the file. Sending EOF. Zmodem is trying to tell the receiver that he has finished sending the file and that it will shortly be sending another file (if there is one more to be sent). Sending file... Zmodem is in the process of sending a file. Sending ZRQINIT. This indicates that Zmodem sending routine is trying to get the transfer started by sending the prompt to the receiver to make it start up. Setting start position This indicates what position within the file the sender will be starting the file transfer from. Generally it is 0, meaning the start of the file but when the receiver wants us to resume a file transfer it will indicate some other position within the file. This is not an error message. TIMED OUT!!!!!!!!! An Xmodem, Xmodem-1k, Ymodem or Ymodem-G file transfer has aborted because it has waited too long to either send or receive a file. This can be caused by either end becoming stuck because it missed the XON character after the XOFF character had been received. If this occurs often enough, please contact me at my E-mail address. Timed out waiting for entire buffer to clear. This message will appear in the log if the log is switched on via the "-l" switch. Zmodem has timed out while trying to clear the current transmit buffer. This points to a serious error in your system setup or the actual 8250, 16450 or 16550 chip. Try the transfer using a different protocol and if the situation persists then have the chip replaced. If you believe it is this program's fault then please send me a message via E-mail (if you are registered). MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 35 Timeout. Either the receiver or transmitter routines have timed out while waiting to receive or send data. This generally means that the other end has been delayed (maybe it is a slower machine than yours) or that your machine is taking too long to handle the output of data. This is not a serious problem but can indicate a loss of carrier if the "-c" switch was not used. Maybe you should try the "-t" switch which will create a time out value more in line with the Baud rate than the standard time out value. Timeout (?? tries) Xmodem, Xmodem-1k, Ymodem, Ymodem-G has continually timed out. The "??" is substituted with the number of tries so far. It is quite possible that you have lost connection with the other end. If you have not specified the "-c" switch on the command line then it may be wise to do so in the future. Too many repositions! Zmodem has got sick of repositioning to the same point in the file. This generally indicates there is a problem with the receiver receiving our packets and may indicate an extremely noisy line or the fact that Zmodem has somehow got entirely out of sync. Unable to allocate enough memory for I/O Buffer! (??) MPModem has failed to obtain enough memory from the free memory pool and thus cannot run in the current environment. If you are multi-tasking then increase the allocation of memory for MPModem. If you are not then removing some of the TSRs will help alleviate the problem. If there is still not enough room then you may have to reduce the size of any disk cacheing or BUFFERS. Unable to allocate memory (1k) The sending routine of Zmodem could not obtain enough memory from the free memory pool. All it needs is a lousy 1024 bytes of memory so please adjust your memory requirements accordingly. MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 36 Unable to create a unique filename. When a file is received by Ymodem, Ymodem-G or Zmodem and you do not want files to be resumed (Zmodem only), and the file name received is the same as an existing one, then MPModem will endeavour to create a unique filename. Generally, it will replace the last character in the file extension (if it has one) with the letter 1, or if that fails 2 or if that fails 3 and so on. For example, suppose we already have a file called "test.txt" and suddenly Ymodem says it has another file called "test.txt". MPModem will now check to see if there is a file called "test.tx1". If not it will create such a file. If there is then it will create a file called "test.tx2" and so on until it gets to "text.999" before it aborts! This situation should never happen. Unable to open file. Well just as it says, MPModem was unable to open the file. If you are transmitting something, then this can indicate that the disk is bad, the file is bad or it is just plain missing. Fix it if possible. If it's missing, then perhaps you typed the name wrong? If you are receiving a file then it means you either have a bad disk or you are receiving a file from a remote site (like a Macintosh (tm) System) and have not specified the "-m" switch. Do so now and start again. Verifying CRC of file. In Zmodem, it is possible for the remote system to request a CRC of the file you have just received. It is a means of trying to ensure correct reception of data not just over the telecommunications line but also in the writing of the file to disk. Waiting for receiver. Zmodem sending routine is now waiting for the sender to get back in synchronization with us. This is a normal occurrence at the end of each file. Waiting to send file(s). The Zmodem send routine is now waiting (patiently I might add) for the receiver to give it instructions on various important aspects of the file transfer. Without these instructions, Zmodem cannot proceed. MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 37 7.0.1 Report File Messages --------------------------- Detailed below are the various report file (MPMODEM.RPT) messages that appear when you run this program from a BBS. <Usernumber> has received all of file <filename> This tells the sysop that <Usernumber> (A user's system number) has received all of <filename>. Because MPModem did not have time to close off and do all necessary file handling the user has essentially got the file for nothing. The Sysop may want to note the users that continually have this "problem" because they may be experiencing real problems or they may have a "re-coded" version of Zmodem. Unable to create unique filename. File: <filename> MPModem tried to create a unique filename for <filename> but failed. This either indicates disk/storage media problems or you may already have upto 999 connotations of the filename. The latter is highly unlikely as you would have to have: (assuming the filename is "FRED.CPT") FRED.CP1 FRED.CP2 . . . FRED.999 This means that you would have to have 1000 files (as detailed above) and this would be unlikely. If it is neither of these then contact the author (after you have tried again to receive the file). Existing file cannot be overwritten. File <filename> The <filename> being received already exists on your system and is either Read-Only, Hidden, System or a Volume Label Name. Either way, this is not a serious message as MPModem will simply reject such files. File positioning error. This can happen when both receiving and sending. Generally this indicates (when sending) that the receiver has asked us to reposition past the End-Of-File. The same can go for receiving. Generally, it is wise to assume that it could be a disk problem so run CHKDSK or its equivalent and perhaps some type of disk diagnosis tool to assure yourself that the disk media is not at fault. MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 38 8.0 Acknowledgements --------------------- The author wishes to acknowledge the following people: Chuck Forsberg - The creator of Zmodem. Ward Christensen - Creator of Modem.Asm (1977) Keith Petersen - Adapted Modem.Asm for RCPM (Remote CP/M) systems and called it Xmodem. Gary S. Brown - The 32 bit CRC code. Joe Campbell - "C Programmer's Guide to Serial Communications" An excellent reference book written clearly but perhaps not concisely. All products mentioned in this documentation are trademarks of or copyright to their respective owners. MPModem v1.54 Copyright (C) 1992, 1993, M. Jose Page 39 9.0 Errors or Omissions ------------------------ Please advise the author of any errors or omissions that appear in this manual. Contact me at the addresses specified in the "REGISTER" file. Thank you for supporting this software. Enjoy. 9.1 Other things ----------------- Oh yes, almost forgot. This program was written in Borland's Turbo C 2.x. What a great product of which I whole heartedly endorse to all programmers whether you be novices or experienced hackers. Some parts were developed using Microsoft C v5.x - these were then "converted" to compile under Turbo C. While Borlands' manuals are great I wish they would make them spiral bound so that the spines do not break! I suppose if that is the only complaint then it's a rather trivial one. :-)