<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>
Date   : Fri, 01 Jun 1984 11:52:33 EDT
From   : David Towson (CSD) <towson@Amsaa.ARPA>
Subject: Re: what is modem7??

Sean - Both MODEM7 and UMODEM use the same basic protocol, originally designed
by Ward Christensen and commonly known as the Christensen Protocol.  However,
the original protocol used a checksum method of verifying the accuracy of each
128-byte block sent, whereas updated implementations of the protocol ALSO allow
the option of using a more complex (but more capable) cyclic redundancy code,
or CRC, checking scheme.  MODEM7 is a step in the evolution of Christensen
Protocol programs.  An offshoot is the MDM7xx series of programs.  The 
particular program you have may or may not be the actual variant known as 
MODEM7, and it may or may not allow CRC checking.  In any case, UMODEM does NOT
do CRC checking, so will not work with your program in that mode.  If your
program defaults to CRC mode, it may eventually switch to checksum mode after
some number of failed attempts to transfer the first block.  Depending upon how
long it takes for the switch to occur, UMODEM may time-out and quit.

     I suggest you try this:  First verify that UMODEM is more-or-less working
by giving it the command (from a terminal) to send a file.  Assuming that
UMODEM starts up and displays messages that say it is going to send so-and-so
file of such-and-such length and so on, then YOU play the role of the receiving
program (still using your terminal).  Send UMODEM a control-U (which is the
ASCII "NAK" character), and if it is working, UMODEM will send the first block.
If you get the first block on your screen, send another control-U.  This will
tell UMODEM that you have received the block in error, and that UMODEM should
resend that block.  You should get it again on your screen.  You should be able
to repeat this until you reach UMODEM's error count limit, at which time UMODEM
should abort and return you to your host's operating system (i.e., UNIX).  On
the other hand, if you answer a UMODEM transmitted block with a control-F
(which is the ASCII "ACK" character), UMODEM should send the NEXT block.  You
can play around to your heart's content this way, until you are satisfied that
UMODEM is (or isn't) working.  Because of control-structure changes between
BSD 4.1 and 4.2 UNIX, changes to UMODEM are required to make it work on 4.2.
Be sure yours is working.

     If you find that UMODEM is working, then make certain that your "MODEM7"
is operating in checksum (not CRC) mode.  I have not personally used the real
MODEM7 (which you may or may not have), so I know nothing about the command
set or help facility (if it has one).  Perhaps someone else will comment on
that.  Does your program work okay in terminal-mode?  Are you connected 
directly to the UNIX computer?  Your program may not tolerate the delays of a
packet-switching network between you and the UNIX machine.  Are you operating
over an 8-bit path?  Although UMODEM has an optional 7-bit mode, your program
almost certainly does not.  The original Christensen Protocol requires an
8-bit path because of the way block numbers are encoded for error checking.
It won't work over a 7-bit path.  UMODEM should be putting the UNIX machine
in 8-bit "raw" mode.  You can check this by turning on the UMODEM parameter 
display mode with a "p" in the command line.  For example, you might use

       umodem -stp filename.

It is a good idea to have a printing terminal when you do this, as the output
is rather voluminous.  Good luck.


Dave
towson@amsaa.arpa
<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>