home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
High Voltage Shareware
/
high1.zip
/
high1
/
DIR10
/
MPMOD154.ZIP
/
MPMODEM.DOC
< prev
next >
Wrap
Text File
|
1993-09-01
|
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. :-)