MPModem v1.60 Implements Xmodem, Ymodem & Zmodem all in one package. Includes many custom enhancements like Fast transmissions, Compressed transmissions and large block transfers. (C) Copyright All rights Reserved. Mark Jose This manual is Copyright (C) to M. Jose. MPModem v1.60 Copyright (C) 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 ......................................... 6 3.0 What equipment do I need? .................................. 10 3.1 Configuring MPModem with MPConfig .......................... 10 3.1.1 File Transfer Options Screen ............................ 11 3.1.2 General Setup Options Screen ............................ 16 3.1.3 Modem/Port Options ...................................... 19 3.1.4 Communication Port Addresses ............................ 21 3.1.5 Miscellaneous Items ..................................... 22 3.1.6 Screen & Colours Setup .................................. 24 3.1.7 Save Configuration ...................................... 25 4.0 Running MPModem from DOS ................................... 26 4.0.1 BBS Users ............................................... 30 5.0 File Formats ............................................... 32 5.0.1 Input File .............................................. 32 5.0.2 Log file format ......................................... 32 5.0.3 Report file format ...................................... 33 6.0 Future Enhancements ........................................ 34 7.0 Messages ................................................... 35 7.0.1 System Messages ......................................... 35 7.0.2 Report File Messages .................................... 48 8.0 Exit Codes ................................................. 50 9.0 Running MPModem from a Bulletin Board ...................... 52 9.0.1 Reading the log file to obtain transfer details ......... 54 10.0 Executing commands with Zmodem ............................. 55 11.0 Acknowledgements ........................................... 56 MPModem v1.60 Copyright (C) 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, all files written by the author and the format of files generated by the programs MPModem.Exe, MPConfig.Exe, and Cfg-Conv.Exe. This includes the configuration file (MPModem.Cfg), the log file (MPModem.Log), the report file (MPModem.Rpt) and any other files other than files transmitted through this program. (1) 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. Any source is provided free of charge. You may use the source code within your own programs SO LONG as you include that source as part of the distribution of your program, just like MPModem has done. You may make changes to the source code and redistribute, so long as you keep any existing copyright notices intact. Please annotate where appropriate. You MAY NOT use the source code in your programs WITHOUT including the source with the distribution containing your program. The reason is simply to allow others to use the code and therefore everyone benefits. Failure to adhere to this simple rule means you CANNOT use the source code or any derivative thereof in your programs. To do so is to violate international copyright conventions. ---------- (1) In other words, any files you send or receive using any of the protocols contained within MPModem are (of course) copyright of their respective owners and as such cannot be copyright to me. Any other files created by MPModem and related programs for statistical and or control purposes are the copyright property of the author. MPModem v1.60 Copyright (C) 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 Board(s) a specific fee to download this product. MPModem v1.60 Copyright (C) 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 Fast-style file transfers, large block transfers and compression. 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. I have also implemented my own version (non-copyrighted) of a very basic compression routine first used by Richard B. Johnson in his program Jmodem as well as a Fast mode transfer based on PCý's "Turbo" transfer. The difference between mine and PCý's version is that mine does not use variable length headers which are copyrighted to Chuck Forsberg. This version incorporates larger block sizes than normal Zmodems. This is loosely based on the "ZedZap protocol" which allows for Fido-style mailers to transfer Zmodem blocks of up to 8192 bytes (as against the norm of 1024). This process is rather clumsy in that it just increases the size of the blocks until it either receives an error or reaches its maximum blocksize of 8192 bytes. My system uses a much better way (in my opinion) which allows the sender and receiver to negotiate the ability to transmit large blocks and then defaults to a maximum block size of 4096 bytes. 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 buffers and large block transfers). 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), to set larger disk read/ write buffers and larger/smaller communications I/O buffers. MPModem v1.60 Copyright (C) M. Jose Page 5 This page intentionally left blank. MPModem v1.60 Copyright (C) M. Jose Page 6 2.1 The MPModem Screen. ------------------------ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ Zmodem Receive (1) ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄ´ ³ Pathname: (2) ³CAR³(26) ³ Filename: (3) ÃÄÄÄ´ ³ ³BIN³(27) ³ Check Type : CRC-16 (4) Blocks Expected: (9) ÃÄÄÄ´ ³ Error Count : (5) Blocks Received: (10) ³FST³(28) ³ Last Frame : (6) Approx. Cps : (11) ÃÄÄÄ´ ³ ³CMP³(29) ³ Transfer Time: (7) Bytes Expected : (12) ÃÄÄÄ´ ³ Elapsed Time : (8) Bytes Received : (13) ³LOG³(30) ³ ÃÄÄÄ´ ³ Messages: ³MOD³(31) ³ Initialising file transfer. (14) ÃÄÄÄ´ (15)³ (16) (17) (18) (19) (20) (21) (22)³KIL³(32) ÃÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÂÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÅÄÄÄ´ ³RX: ³Port: 1³FIFO: 4³ ³ ³Space: 133447936 bytes³ 5³BIG³(33) ÃÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÁÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÁÄÄÄ´ ³ Version 1.60 MPModem (C) Copyright 1993 M. Jose ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ (23)³ ³ Baud: 19200 ³Time on : 0 ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ (24) (25) (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. This field will display "Transfer Time" if you are receiving/downloading a file and will display "Time Left" if you are sending/uploading a file. (8) "Elapsed Time" is the total amount of time so far taken to receive or send the file. MPModem v1.60 Copyright (C) M. Jose Page 7 (9) 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. (10) 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. (11) "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. (12) 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. (13) 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. (14) This field displays any error and system messages. (15) 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). (16) This box will contain the remote's version number if the remote program sends this information. MPModem sends and receives this information. The ability to do so will also enable future features. (17) This box contains the current port number you are running MPModem off. Be aware that what you set as the port number in the configuration program (MpConfig) will override the port specified on the command line with the "-p" option. (18) This box will tell you if your UART chip has a FIFO buffer and if so it will display the number of bytes that will be buffered. If no chip is present or you have turned off this feature via the MpConfig program, then "NO" will appear. (19) 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. MPModem v1.60 Copyright (C) M. Jose Page 8 (20) This is the compressed block size. This will only display when both you and the remote have activate compression. (21) This is the current amount of free bytes left on the disk where the receival 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. (22) 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. (23) This field can contain the name of the current user (if you are a BBS operator) or the name of the current system you are connected to. To have this information displayed, you must pass it to the program using the "-v" switch. Refer to the reference to "-v" later in this documentation. (24) This field displays the terminal speed of the program. With high speed modems (that use compression to "cheat"), this value will differ from the actual modem to modem speed (also known as the carrier speed). This baud rate is commonly called the connect rate. (25) This field displays the amount of time left of the current user (if you are running a BBS) or the amount of time you have been online to the remote host. Some terminal programs allow you to pass to this program the amount of time you have been online. MpModem will then continue to display the time expended. To have this displayed you need to specify the "-t" switch. Refer to the documentation for more details. (26) 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). (27) 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). (28) If we are running in fast mode then it will contain the letters "FST". This mode of transmission does not escape special characters that the traditional Zmodem will do. In this case, the transmission has less overhead. The actual speed increase depends very much on what is in the file. Files full of Telnet escape characters will be dramatically faster if sent using this method. MPModem v1.60 Copyright (C) M. Jose Page 9 (29) When a transmission is to be made while trying to compress the data, this box will contain the letters "CMP". MPModem will only ever send a compressed packet when the compressed length of the block of data is less than the uncompressed block of data. (30) 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 option "Always log file transfers?" in the "File Transfer Options" section of the MpConfig program is set to "Y". This is MANDATORY for sysops - unless of course they don't like to keep track of what files the users send and receive! (31) 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). (32) If "KIL" 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. (33) When this box displays "BIG", both you and the remote end have invoked MPModem with "-l" which allows you to transmit and receive blocks of up to 4096 bytes (rather than 1024). MPModem v1.60 Copyright (C) M. Jose Page 10 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. The program takes up about 80k with an additional 10k after startup. That means around about 90k in total. If you increase the size of the disk read/write and/or communications buffer, then you will also increase the overall memory usage. Likewise, if you are running a Zmodem session and using large blocks (via the "-l" switch) then the overall memory requirements increase by about 10k. Keep in mind that this amount of memory is used IRREGARDLESS of whether the remote end can send or receive with large blocks. A safe memory amount would be about a minimum of 256k or much more if you are running this from a BBS. As well you will require a COM1: to COM8: serial port(s) which use an 8250, 16450, 16550 or similar 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 º º Modem/Port Options º º Com. Port Addresses º º Miscellaneous Items º º Screen & Colours Setup º º Save Configuration º º º º º ÌÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͹ º MPModem º º Copyright (c) 1993 v2.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.60 Copyright (C) M. Jose Page 11 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?............. Y º º Delete a failed transfer? (Receiving).............. N º º Allow remote to execute programs/commands?........... 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?................. N º º 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 º º Always Escape all control characters? (Zmodem only).. N º º Use current Comm. port settings for Baud rate?....... N º º º º º º º ºWatch for Modem Hangup, dropped lines etc. º ÇÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĶ ºEsc: Exit, : Move MPModem Configuration Copyriº ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ 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.60 Copyright (C) M. Jose Page 12 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. It executes the unix command of "SH.EXE" for shell. If you want the equivalent for DOS then check your local BBS for one and rename it as "SH.EXE" and place it in your MPModem directory. The default is 'N'. 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'. MPModem v1.60 Copyright (C) M. Jose Page 13 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'. 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. MPModem v1.60 Copyright (C) M. Jose Page 14 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 "-y" 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. Force the sender to resume with CRC check? BLANK. 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'. MPModem v1.60 Copyright (C) M. Jose Page 15 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". Always 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!) MPModem v1.60 Copyright (C) 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 º º Enter size of Receive Communications buffer. (1 to 20k) 2 º º Enter size of Transmit Communications buffer. (1 to 20k) 1 º º If running from a BBS, enter port number. (1 to 8) 0 º º Wait for user to ACK. (32 to 1024 bytes) 0 º º Use sub-packets. (24 to 1024 bytes) 0 º º º º º º º º º º º º º º º º º º º º º º º º º º º ºThe larger the buffer the less disk writes per transfer. º ÇÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĶ ºEsc: Exit, : Move MPModem Configuration Copyriº ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ Enter size of Disk I/O Buffer. (1 to 20k) This allows you to specify the Disk Read/Write buffer. 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. Be aware that should your system freeze or "collapse" in some way, any bytes yet to be written to disk WILL BE LOST!! MPModem v1.60 Copyright (C) M. Jose Page 17 Enter size of Receive Communications buffer. (1 to 20k) This option lets you set the receive communications buffer size as used by the internal interrupt routines of MPModem. The optimum setting is around 2 (2k or 2048 bytes) but you may find your system runs better with a larger buffer of say 4 (4k or 4096 bytes). Generally the latter is the case if you are running under a multi-tasker and are doing some intensive work in one of "windows". If you experience CRC errors and the like when receiving using Zmodem, then try setting the buffer higher. The reason you are getting these errors is your machine just isn't coping too well with all the strain. (Poor thing...) Enter size of Transmit Communications buffer. (1 to 20k) This option allows you to modify the transmit buffer used by the internal transmit routines of MpModem. Generally there will be no reason to change this buffer, but if you wish the option is there for you. I have experienced problems with some modems not liking a big buffer when transferring only a small file. For example, if you have a Transmit buffer of 4k but your file is only 3k, a couple of modems have trouble. The result is Zmodem has to wait for a timeout before trying to end the transfer. If you set a big buffer and this occurs then you are best to go back to a smaller buffer. 1k (or 1024 bytes) is the default. 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. 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. MPModem v1.60 Copyright (C) M. Jose Page 18 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.60 Copyright (C) M. Jose Page 19 3.1.3 Modem/Port Options ------------------------- The following is the screen which is displayed when you select the "Modem/Port Options" off the master menu: ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͵Modem/Port OptionsÆÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» º º º Enable FIFOs (only applies to 16550A series chips)........ Y º º Number of bytes before interrupting. (1/4/8 or 14)........ 4 º º º º º º º º º º º º º º º º º º º º º º º º º º º º º º º º º ºTurn on UART buffer if there is one. Applies ONLY to 16550 & similarº ÇÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĶ ºEsc: Exit, : Move MPModem Configuration Copyriº ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ Enable FIFOs (only applies to 16550A series chips) You can turn on or off the use by MPModem of the FIFO buffer by setting this option. Generally you would want to use the FIFO buffer (if you have a chip with it) but in the case where you neither need nor want it, then just set this option to N. Soapbox: The 16550 chip (and its consequent buffer) is a somewhat over-rated chip. It seems to have become a necessity because of badly designed systems and even worse written software. I have thrashed the living daylights out of a system with 16450 chips and experienced no problems. Yet I can take the same software to another machine and experience nothing but problems. A 16550 type chip will not save you from badly written communications code. (I hope mine doesn't fall into this category!) MPModem v1.60 Copyright (C) M. Jose Page 20 Number of bytes before interrupting. (1/4/8 or 14) This allows you to set the buffer used by the 16550 (and compatible) chips. The optimum buffer size seems to be around 4 bytes. Setting it to 1 makes it effectively act like a normal unbuffered chip like the 16450 and its predecessor, the 8250 series. MPModem v1.60 Copyright (C) M. Jose Page 21 3.1.4 Communication Port Addresses ----------------------------------- ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͵Com. Port AddressesÆÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» º º º Port Base º º Name Address IRQ º º º º COM1 3F8 4 º º º º COM2 2F8 3 º º º º COM3 3E8 4 º º º º COM4 2E8 3 º º º º COM5 3F8 4 º º º º COM6 3F8 4 º º º º COM7 3F8 4 º º º º COM8 3F8 4 º ºStarting address of port 1. º ÇÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĶ ºEsc: Exit, : Move MPModem Configuration Copyriº ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ Selecting this option allows you to change the base address of the communications port you are running off (1 to 8 are the only supported ports) as well as the Interrupt ReQuest line number corresponding to that port. The above values are the accepted defaults. DO NOT CHANGE them unless you know what you are doing. When setting port addresses, ensure you follow your multi-port installation guide. There's nothing more infuriating than seizing your system because of a wrong base address or IRQ. MPModem v1.60 Copyright (C) M. Jose Page 22 3.1.5 Miscellaneous Items -------------------------- ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͵Miscellaneous ItemsÆÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» º º º Date format DDMMYY º º Date separator - º º Time format 24 º º Time separator : º º º º º º º º º º º º º º º º º º º º º º º º º º º º º ºValues DD (Day), MM (Month) and YY (Year) º ÇÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĶ ºEsc: Exit, : Move, .: Change value MPModem Configuration Copyriº ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ This is the Miscellaneous menu. Currently this menu is selected when you need to change the format of the time as displayed in both the log file (MPMODEM.LOG) and the report file (MPMODEM.RPT). Date format There are three formats available. The default is DDMMYY which is commonly referred to as the "European" format. It is also used by Australia and New Zealand and so on. The next format is MMDDYY which is used by countries such as the USA. The last format available is the international format of YYMMDD. DD represents the days, MM represents the month, and YY represents the year. To cycle through the various date formats, press the right or left cursor keys. MPModem v1.60 Copyright (C) M. Jose Page 23 Date separator This can be one of the following symbols: - : = . ~ / \ # To cycle through the various separators, press the right or left cursor keys. Time format The time format can either be shown in 24 hour (military) time (which is the default) or as 12 hpur (am/pm) time. When using 24 hour time, the display for 8pm and 25 minutes would be displayed as 20:25:00 (assuming a time separator of ":"). When using 12 hour time, the display for the same time would be 8:25 pm, again assuming a time separator of ":". Again, to toggle through the two alternate time displays, press the left or right arrow/cursor keys. Time separator See "Date separator", above. MPModem v1.60 Copyright (C) M. Jose Page 24 3.1.6 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 º º º º º º º º º º º º º º º º º ºThe colour of the background of the screen. º ÇÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĶ ºEsc: Exit, : Move MPModem Configuration Copyriº ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ MPModem v1.60 Copyright (C) M. Jose Page 25 3.1.6 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.60 Copyright (C) M. Jose Page 26 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 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". Note also that any filename given on the command line will be ignored and precedence given to the "-@" switch. This switch is optional. -a When using Zmodem this forces the transfers to be -A made 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. Any baud rate is supported, but the general ones used 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. I recommend you DO NOT use this option, but instead configure MPModem (via MpConfig) to use the existing baud rates. The only time this option is necessary is when you have a direct (null-modem) connection. This switch is optional. MPModem v1.60 Copyright (C) M. Jose Page 27 -c Make Zmodem run in compression mode. As long as -C the other end of the transmission can also send using this type of compression, then Zmodem will attempt to compress ALL packets/frames sent. It will, however, only send a compressed packet when that packet is smaller than the uncompressed packet. This switch is optional. -f Run Zmodem in fast mode. This greatly depends on -F the remote's ability to run Zmodem in non-standard mode. This is an adapted version of PCý's turbo mode. The main difference is my version DOES NOT rely on variable headers which seem to be copyright to Chuck Forsberg. This switch is optional. -l Run Zmodem with large blocks. The normal block -L size of Zmodem is 1024 down to around 64 bytes. When this is selected (and the remote can do likewise), then the blocksize will range from 4096 to around 64 bytes. This switch is optional. -n This switch allows you to override normal Zmodem -N practice of defaulting to CRC-32 when protecting the packet and transmit using CRC-16. The overhead is reduced by 2 bytes per packet and on quite safe and noise free lines will offer you protection with the benefit of a saving in the overall transfer time. This switch is optional. -p Defines the port number. MPModem can operate from -P ports 1 to 8. You must specify the port number (1 to 8) directly after the switch, eg. -p1 will make MPModem run from Port 1 of your machine. This switch MAY be optional. If you have used MpConfig to set the port number, then this switch will be overridden. If you have not set the port number in MpConfig, then you MUST specify it on the command line. MPModem v1.60 Copyright (C) M. Jose Page 28 -r Causes MPModem to go into receive mode. You may -R specify 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 -S specify 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 mainly used by BBS operators. -T It enables sysops to see what time is left for the user while running MPModem. It also enables users to keep track of the total transfer time over more than one transfer. This switch is optional. -u Use this switch ONLY when you are running MPModem -U from 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. This switch is optional. MPModem v1.60 Copyright (C) M. Jose Page 29 -v This switch enables users to specify respectively -V the user's name or the system they are attached to. 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. This switch is optional. -w Sound a "warble" when the program has finished -W its transfers. This switch is optional and dependant on the above. -x Put Zmodem into command mode. This switch can be -X invoked on its own or with the further parameter of "W" or "w" which will cause the receiver to quit and then execute the command. If you don't specify "W" or "w" then the receiver/sender will execute the command just like a shell. When the command is finished, control will return to the receiver/sender. To enable this command you must have set the option of "Allow remote to execute programs/commands?" in the configuration program under the option "File Transfer Options" to Y. If you have NOT set this and the remote sender tries to send you a command then it will be rejected and a message reported (for security reasons mainly). For more information, see the section called "Executing commands with Zmodem". NOTE: This command only works when you specify the transfer type as Zmodem (-rz or -sz). -y Put Zmodem into resume mode by force. If you have -Y not specified that you ALWAYS want Zmodem to try to resume a transfer (this is done via the configuration program) then specifying 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. This switch is optional. MPModem v1.60 Copyright (C) M. Jose Page 30 4.0.1 BBS Users ---------------- If you are a BBS operator, then the screen will differ from what "Normal" users will see. At the very bottom of the screen will appear a rectangle which will display the following information: User BBS User --------------------------------------------------------------- BBS Name connected to. Current online user. Baud rate (Connect rate) Baud rate (Connect rate) Time online so far Time remaining User ~~~~ If you can pass to the program from your calling communications program like Telemate, Procomm or Telix the following information, then 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! 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 typing ALT-S and selecting the relevant script. MPModem v1.60 Copyright (C) M. Jose Page 31 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. MPModem v1.60 Copyright (C) M. Jose Page 32 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.60 Copyright (C) M. Jose Page 33 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.60 Copyright (C) M. Jose Page 34 6.0 Future Enhancements ------------------------ MPModem is by no means complete and will be continually updated to ensure users are able to use the most modern aspects of the protocols that make up the MPModem product. Don't expect the updates to be thick and fast - as the old adage goes - you get what you pay for. As you paid nothing, expect no more... If you have general problems with the program I would be more than pleased to know about them. MPModem v1.60 Copyright (C) M. Jose Page 35 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. Break detected - receiver interrupted. The communication routine has detected a break signal sent by the remote (the sender) to you (the receiver). This will cause the protocol to lose some characters. The communication routine will wait for the next byte to arrive correctly. MPModem v1.60 Copyright (C) M. Jose Page 36 Cannot resume transfer - entire file already received. Zmodem has been instructed to try to resume a transfer (either by the -Y switch on the command line or as defined in the Configuration program (See section 3.1.1, "File Transfer Options Screen") but cannot do so because the file to be sent is the same size as the one we already have. In this instance, we have had to reject the file. If the file is not the same, then turn off resume (either do not specify "-y" on the command line or set the appropriate question in section 3.1.1 to 'N'). This will make MPModem create a unqiue filename. Carrier Lost. If you have set MPModem to watch for carrier dropouts then when such an event occurs, MPModem will report this message. Note that if you are direct connecting it would be wise to not monitor the carrier signal and thus avoid a possible problem. Command file missing. Read the manual. You have invoked MPModem with the "-x" switch (you may have also invoked it as "-xw") and MPModem expects to find the command you wish the receiver to execute in the file called "MPMODEM.CMD". This file should be in the same directory as your MPMODEM.EXE, and MPMODEM.CFG file. If it isn't there then MPModem will not find it. Simply relocate it to there and re-run MPModem. Please refer to section 10, "Executing commands with Zmodem" for full details of how to go about sending commands. Command successfully sent to receiver. A command sequence located in the "MPMODEM.CMD" file has been loaded and sent to the receiver successfully. If the receiver can handle the command, it should execute it and finish. Data overrun. System load too high. The system has been unable to act quick enough to take an assembled byte from the UART (8250,16450 or 16550 type chips) prior to the next byte having been received and assembled. This can be caused by a broken (incorrectly coded) receive routine but is more likely the result of too high a system load - especially when you are multi-tasking. After all, DOS is not a multi-tasker and the manipulation that has to go on to simulate this is a credit to the writers of this code. MPModem v1.60 Copyright (C) M. Jose Page 37 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! 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 pointing your finger at the remote's network; It's harder to diagnose! Error reading the configuration file!. The configuration file is either corrupt, old or for a version of MpModem other than the one it was intended for. You are best to delete the configuration file called MPModem.Cfg and run MPConfig.Exe to create a new configuration file. 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 packet as 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. MPModem v1.60 Copyright (C) M. Jose Page 38 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. 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. MPModem v1.60 Copyright (C) M. Jose Page 39 Error: Trying for ZSINIT. Zmodem has given up trying to send an initialisation 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. FIFO buffer error. One or more bytes garbled. You have the FIFO buffer enabled and since the last read of the buffer 1 or more of the bytes in the buffer has been received in error. For more information, see the notes relating to the following error messages: Break detected - receiver interrupted. Framing error. Stop bit wrong. Parity error. Wrong bit sequence. Data overrun. System load too high. 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. MPModem v1.60 Copyright (C) M. Jose Page 40 Framing error. Stop bit wrong. For some reason the stop bit count was either wrong or missing. This can be caused by many things but one thing I am aware of is when running in multi-tasking, you inadvertantly run another program which uses the SAME communications port. If you get this error consistently, then you may wish to contact your modem supplier. 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 then contact me via email 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.60 Copyright (C) M. Jose Page 41 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. Local abort. You have pressed the - (System break) keys. MPModem v1.60 Copyright (C) M. Jose Page 42 MPMODEM.CFG is an old version (??.??). The version should be ??.??. The version of MPModem.cfg is not the right version required by this release of MPModem. You have two courses of action. You can run the "cfg-conv" program to update the configuration file. If this fails to work (quite likely if it is a very old configuration file), then you will havbe to delete it, run MPConfig.Exe, re-set your various options and save the file. You will then be ready to run MPModem. No files to send! When you specify a filename, (can be wildcards like 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. Not enough memory to create command buffers. (????). There is simply not enough memory left to create the buffers which have a total length equal to the figure in brackets. (I have placed question marks in the above message). Try freeing up some memory some how. You should only need about 2k to be safe. Parity error. Wrong bit sequence. The wrong parity bit has been received or in other words it is inconsistent with the default setting of N or No parity. This could indicate a problem in the other ends software/hardware sending in the wrong mode or it could mean your modem is playing up. Receiver has entered command mode. This is the last entry made in the log before the shell is executed. The shell (called SH.EXE) will execute the commands sent by the remote (sender) Zmodem. 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. MPModem v1.60 Copyright (C) M. Jose Page 43 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. The most probable reason is that the remote already has the file or the file you are trying to send exists on the remote as a hidden, system or read-only file or even as a directory. Repositioning. This tells you that the protocol is undergoing an error recovery by stepping backwards into the file to replace data, already sent and found corrupt, with the correct data. 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. Request to escape control characters rejected. This can occur in both send and receive mode. What it means is that you have tried to start a Zmodem session with both Fast and Escape Control Character mode enabled (or the sender/receiver has requested it when you want a Fast transmission). Basically the two cannot combine. Fast mode skips all escape encoding (other than Zmodem's special character) whereas Escape Control Characters wants all control characters escaped. See the dilemma? MPModem v1.60 Copyright (C) M. Jose Page 44 Requested COM?. This program only supports COM1: to COM8:. If you got this error message then you obviously specified an incorrect port number; or did you? If you used the command line switch "-p" followed immediately (that is without a space after the "-p" such as "-p1" for port 1), then you must reenter the command line with the correct port number. You may, however, have not specified a port number on the command line. This is fine if you have "hard-coded" the port number you use in the configuration file, but if that also is blank then this message will be generated. Either specify the port number on the command line via the "-P" switch or set it in the configuration program. Sender has entered command mode. At this stage the sender is trying to get the receiver to act upon the commands it is now sending. Depending on whether the receiver allows commands, the command sequence will either complete successfully or be aborted by the receiver. Sender's commands rejected. The Sending side of Zmodem has tried to get us (the receiver) to execute commands. Because you have not allowed this via the configuration program MPCONFIG.EXE, the command is ignored and the transfer completed. 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 it 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. MPModem v1.60 Copyright (C) M. Jose Page 45 Serialisation error returned 0X??. This means that a combination of serial errors was received possibly indicating a dead or near-dead UART chip. To first eliminate a software problem, please record the hexadecimal number (which will be in place of the "??" above) and advise me by email (if possible). 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. 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. 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. MPModem v1.60 Copyright (C) M. Jose Page 46 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. 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. MPModem v1.60 Copyright (C) M. Jose Page 47 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. (NOT IMPLEMENTED) 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.60 Copyright (C) M. Jose Page 48 7.0.2 Report File Messages --------------------------- Detailed below are the various report file (MPMODEM.RPT) messages that appear when you run this program from a BBS. has received all of file This tells the sysop that (A user's system number) has received all of . 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 allowing them to grab files for "free". Unable to create unique filename. File: MPModem tried to create a unique filename for 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 The 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. MPModem v1.60 Copyright (C) M. Jose Page 49 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.60 Copyright (C) M. Jose Page 50 8.0 Exit Codes --------------- The following exit codes are generated when MPModem finishes the session: Code Description --------------------------------------------------------------------- 0 Normal exit. (Could be you or the remote have cancelled the transmission). 1 Carrier has been lost. 2 Invalid baud rate. Out of the supported range of 0 to 115200. 3 Invalid communications port specified on the command line. Supported values are 1 to 8. 4 Unable to open the Configuration files called MPModem.Cfg. Generally a message will be shown on your screen and if MPModem can write to the report file, it will also write the reason in there. 5 MPModem was unable to read the configuration. Possibly the file is either missing or an old version. If it is the latter, then run "cfg-conv.exe" try to update it. Check the contents of the MPMODEM.RPT file - it may contain the answer. 6 MPModem could not read or parse the options contained in the MPMODEM.CTL file. This file should meet the specifications of OPUS.CTL and is used when running this program from a BBS. 7 Unknown transfer option. Type MPModem on its own to see the various transfer options or refer to the relevant section of this manual pertaining to the switches "-r" and "-s". 8 General invocation error. Either you have not specified the right switches on the command line or are missing some of the REQUIRED switches. 9 MPModem has been called with the "-@" switch which causes it to look for a file named "MPMODEM.FIL" in the directory where MPModem resides. (MPModem's directory can be changed with the environment variable MPMODEM). Thus the file cannot be found or opened. 10 Reserved. MPModem v1.60 Copyright (C) M. Jose Page 51 11 You haven't supplied a path/filename for the specified file transfer. Generally this means you have tried to run Xmodem without specifying a filename. Remember Xmodem CANNOT pass the filename to the receiver like Y or Zmodem can. 12 MPModem could not find the command file, MPMODEM.CMD (which should be where the MPMODEM.CFG file is) or it could not allocate enough memory to transfer a command using Zmodem. See section 10 on how to send commands. 99 My program has been tampered with. Either you are breaking the law or a virus has attached itself to your copy of MPModem. If it is the former, may you die a lingering death! If it is the latter, get a virus kit QUICKLY. MPModem v1.60 Copyright (C) M. Jose Page 52 9.0 Running MPModem from a Bulletin Board ----------------------------------------- As of version 1.60 of MPModem, it no longer directly supports bulletin boards (in the past this program supported RemoteAccess - a bulletin board based originally (I think) on QBBS). MPModem does still, HOWEVER, support bulletin boards running it. It does this by using the very common file format of OPUS. The format is (was) based on the standard OPUS.CTL file for filedoors. So long as your bulletin board can invoke this program (which uses little memory) and build a .CTL file called MPMODEM.CTL in the format it requires, then this program will run off your bulletin board. The format required is as follows: Line 1: Port Number (an integer from 1 to 8). Line 2: Baud rate. Line 3: NOT USED. Line 4: Time remaining (in minutes). Line 5: Either the download directory or the start of the upload list. . . . Line xx: End of upload list. Some explanations: The port number can be made redundant by specifying it in the configuration file. See section 3.1.2 "General Setup Options Screen" for more details or just run MPConfig, go to the second menu option and scan down the page for the option to select the port number and make it the default. The baud rate can also be made redundant by specifing in the configuration file that you want MPModem to use the values already set - rather than initialising them. See section 3.1.1 "File Transfer Options Screen". Generally it is advisable to set this to 'Y' because some bulletin boards only pass the carrier rate (rather than the connect rate) to the control file. If MPModem uses this rate your transfers will be garbled and won't even start. NOTE: Both port and baud rate ARE NOT necessary if you select the option in the "File Transfer Options Screen" (see section 3.1.1) called "Use current Comm. port settings for Baud rate?" and set it to Y. This means baud and port settings (except FIFO buffer) will be untouched by MPModem. It is recommended you do the above (even if you supply the port and baud rate). MPModem v1.60 Copyright (C) M. Jose Page 53 Line 5 can be one of two things. If the MPModem program was invoked by someone wanting to send files to your system, then this line will contain the download directory where those files are received into. If the user wants your system to send files, then line 5 (and onwards) will contains the names and paths of the files MPModem will send to the user. If all these criteria can be met, you should have a seamless integration of MPModem into your bulletin board system. MPModem v1.60 Copyright (C) M. Jose Page 54 9.0.1 Reading the log file to obtain transfer details ----------------------------------------------------- Most bulletin board program designers seem to have enough forethought to have allowed for external protocol and the proper handling of them. In this case, they would have also allowed for options, when setting up an external protocol, to enable the extraction of the transmitted or received file and the filename. RemoteAccess is one of those programs. In order for your system to know which files were transferred and what size they were (especially for incoming files), it has to have some way of scanning through the log file (MPModem.Log) and extracting the relevant details. What it needs to be able to do is scan for the following (on each line of the log file): At offset 20 (for compilers which start at 0) and 21 (for compilers which start at 1) is the following important information. "Transmitted:" - One space after this is the full path of the file SENT (downloaded from the BBS). "Received:" - One space after this is the name of the file RECEIVED (uploaded to the BBS). Do not use the "Remote filename:" whih appears in the log file. This could be a strange filename before conversion to DOS. For example, it could be a Macintosh file called "Red Rover Over and Out", which will become a "Received:" filename of "Red_Rove". "Bytes:" - One space after this is the amount of bytes sent or received. If for some reason your system does not allow for this, then search around for a filedoor that will allow you to do this. If you still have no luck then let me know, perhaps I could write a quick filedoor to correct the problem. ANY requests for MPModem to write DSZ style log files will be rejected outright. As the log is part of the author's (of DSZ) copyright, it too falls within these bounds unless specifically denounced. So there! MPModem v1.60 Copyright (C) M. Jose Page 55 10.0 Executing commands with Zmodem ------------------------------------ Make sure you have read the information regarding the relevant switch "-x{w}" prior to reading this section. MPModem allows for the sending of command sequences to the remote end which will then (if allowed) execute those commands or even exit to a shell (which is called SH.EXE). Commands can ONLY be sent by the sender and can only be executed by the receiver. All commands are to be in the MPModem path (set by the environment variable MPMODEM or else it defaults to the path where MPModem was executed from) in a file called MPMODEM.CMD. Only one line of commands are allowed. Any more than one line is ignored. For unix systems this isn't a problem as you can separate several commands using the ";" such as: ls -lFR>report;cat bozo>>report;grep -i "last:" report>grep.rep For DOS systems, well, too bad... If you want to execute a program, then you can enter the command as such: program {parameters} (The combination is for DOS.) Therefore to execute a shell (on DOS or Unix or whatever), then your command would be: sh scripttorun MPModem send routine will send this command to the receiver, and providing the receiver is allowed to and can perform the above command, it will do so and end the current Zmodem trabsfer session. So feasibly you could send the file "scripttorun" and providing this download goes to the current directory in which MPModem resides, you could then send the above command and execute it. The maximum length of a command is 1024 bytes (including the CR/LF combination). An example command file is included and a dummy script program called "SH.EXE" are included. It doesn't do much but show you how commands can work. Put the SH.EXE program in your MPModem directory and enable commands via the configuration program. Then get the sender to send the command. If you are using MPModem to send the command, then get them to place the MPMODEM.CMD file in the MPModem directory and specify a command line like: "mpmodem -sz -p? -b???? -x". MPModem v1.60 Copyright (C) M. Jose Page 56 11.0 Acknowledgements ---------------------- The author wishes to acknowledge the following peoples' work: 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. A good starting text. Ward Christensen - Creator of Modem.Asm (1977) & Ymodem. Chuck Forsberg - The creator of Public Domain Zmodem (under a Telnet contract). Keith Petersen - Adapted Modem.Asm for RCPM (Remote CP/M) systems and called it Xmodem. All products mentioned in this documentation are trademarks of or copyright to their respective owners.