informis
/
textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/computers/DOCUMENTATION/jmodem.txt

1072 lines
36 KiB
Plaintext
Raw Permalink Normal View History

Initial commit
2021-04-15 11:31:59 -07:00
J M O D E M
File Transfer System
Compliments of
Richard B. Johnson
PROGRAM EXCHANGE
(303) 440-0786
December 31, 1988
General:
First Let me get this over with.
MS-DOS is a registered trademark of Microsoft Corporation
IBM, IBM-PC, IBM-XT, AT, are registered trademarks of
International Business Machines, Inc. WILDCAT! is a
trademark of Mustang Software. XMODEM is a public-domain
file-transfer protocol developed by Ward Christensen.
JMODEM is released into the public domain. As with most
public-domain protocols, you are advised that there is no
implied warranty of any kind. The source-code is provided so
that you may determine for yourself if this program may
serve a useful purpose. It is written in Microsoft MASM
Assembly-language using good standards of engineering
practice. It does not use any strange or "undocumented"
functions of the MS-DOS operating system.
PLEASE UPLOAD THIS FILE (The ARC file) to as many
BBS systems as you can so that it gets installed
all around the country.
Introduction:
JMODEM is a new file-transfer protocol developed to be used
as an "external protocol" on BBS systems and personal
computers using the IBM-PC/AT/XT structure and the MS-DOS
operating system.
This file-transfer system features:
o 16-bit CRC for verification
o File size is exactly maintained
o Data compression.
o Rapid host/remote synchronization.
o Variable-length transmission blocks which,
if there are few errors, increase to 8192
data-bytes in length.
o Flow control (automatic)
o Hangup protection
o Aborted files are saved
o Files being overwritten are renamed to
".OLD", rather than deleted.
o COM1 - COM4 support.
o Interrupt on received characters allows data
to be received while the previous block is
being written to disk. This provides almost
continuous data transmission without long
waits between blocks.
- 1 -
JMODEM Protocol Page 2
JMODEM is not for everyone! It does not have any pretty
screens to dazzle the user. It is designed to maximize the
amount of data that can be transferred in a given time (and
reduce telephone cost). It does this by sending very long
blocks of data and encoding (compressing) the data wherever
possible. Since long blocks of data are subject to many
transmission errors, a 16 bit CRC is used to determine the
data integrity. As many as ten retries are made if the data
is not correctly received. If you have a noisy telephone
circuit, you will find that JMODEM will abort more often
than the XMODEM protocol which sends very short blocks. A
future version that will be downward-compatible with the
existing version is being developed that will do "heroic"
retries and will even go down to a 16-byte block-lengths if
that's what is necessary to get the data transferred.
Once synchronization between the remote computer and the
host are established, JMODEM paints a status block on the
screen that shows how the file transfer is going. The status
screen shows the block being transmitted (or the last re-
ceived), the length of the block, and the total bytes having
been transmitted (or received). A special synchronization
routine is used so that the first block is not thrown away
as happens so often in XMODEM type routines. During the
synchronization routine, where the host is waiting for the
user to enter the proper file parameters (a 30 second wait).
You can abort immediately by sending a control X (^X). After
actual file transfer begins, ie. when you see the status
window on the screen, no input from the keyboard is pos-
sible. You send a control BREAK to abort the transmission
(or ^C). In this case, the program will abort after the
block being sent/received is complete. This could take 15 or
more seconds with long blocks so be patient.
In the event that carrier is lost (the user disconnected),
the file-transfer program will also abort. This, too, could
take as long as 15 seconds. JMODEM has logic to determine if
the modem carrier was present when it started. This will
allow you to transfer files between computers with a wire
without having to tie the RLSD lead high.
How it works:
The block size starts out at 512 bytes (or the actual bytes
in the file -- whichever is less). To this is added a 6-byte
overhead. If the block transfer occurred without any
retries, the block length is increased by 512 bytes to 1024
bytes. As long as the transmission was successful without
incurring any re-tries, the block-length increases to a
maximum of 8192 bytes. There is still the same 6-byte
overhead so the maximum block length will actually be 8198
bytes. Any time there are retries, the block length (on the
next new string) is decreased by 512 bytes. The string-
length is never reduced to less than 512 bytes due to
- 2 -
JMODEM Protocol Page 3
errors. When the last bytes are read from the file, the
block length may be as little as 7 bytes (one data byte,
plus the 6 byte overhead). The file size as received will be
exactly the file size as transmitted. XMODEM will "round-up"
the file size to the next higher block. This means that MS-
DOS's COMP (compare) will always fail when you attempt to
check files that have been sent by XMODEM and many other
protocols.
When the file is read, an attempt is made to compress the
data using the well-known RLL process where multiple bytes
are compressed into a 4-byte statement.
For instance a string that looks like this (hex):
A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0
Gets compressed into this:
BB 0F 00 A0
| | | |__________ Byte to repeat
| | |_____________ High byte of repeat length
| |________________ Low byte of repeat length
|___________________ Sentinel Byte
The sentinel-byte (BBH), when encountered in a data stream
will get expanded to four bytes. Therefore, it is possible
for the "compressed" data string to actually be longer than
the original. If this occurs, the original string is sent
rather than the longer encoded one. Since the kind of data
sent can be different from block-to-block, it is necessary
to send a control-byte along with the data so the receiver
had determine how to operate on the data.
This is the control structure:
00 02 00 0B 01 02 03 04 05 06 07 08 09 0A .... 0A EA
| | | | | | |_ CRC
| | | | | |____ CRC
| | | | |______________________________________ data
| | | |_________________________________________ rec.
| | |____________________________________________ control
| |_______________________________________________ length
|__________________________________________________ Length
Two bytes are used for the string length and two bytes are
used for the CRC. As is standard in memory, the high-byte
looks "to people using DEBUG" swapped with the low byte. The
data is transmitted exactly as the memory image.
The length (a word) begins the string so the receiver may
know exactly how may bytes to receive.
The control byte is bit-mapped to 8 possibilities. The ones
most important are:
NORMAL DATA
- 3 -
JMODEM Protocol Page 4
COMPRESSED DATA
END OF FILE
ABORT
This is now the receiver "knows" what to do with the data.
The CRC is generated using this polynomial:
X = X + X^(2(n-mod 7))....... Where n = t(n-1)
And t = string length
It has the advantage of simplicity in assembly-language
programming and will detect errors with a probability of
about one undetected error in 2^132 (which is a very large
number). It does not correct errors so its not important to
use some "standard" function to generate the CRC.
Support for COM3 and COM4 have been added on revision level
V1.05 . Note that the standards for port locations are de-
facto standards only and may not be the ports actually used
in your computer. Please modify the communications port
structures at the beginning of the assembly-language program
to match your system parameters if they are different. The
modifications should be done to the STRUCTURES, not to the
EQUATES!
Revision level V1.09 brings musical exit status. If the file
transfer was successful, the computer plays "victory". If
the file transfer was aborted, the computer plays "retreat".
Since the BBS SysOp is unlikely to want his computer to play
bugle-calls well into the evening, the user has the option
of turning the music off. This is done by setting an
environment variable string:
SET JMODEM=SHUTUP
... Will accomplish the desired result.
Usage:
This program uses parameters on the command line.
JMODEM S <filename.typ> ( Sends a file to COM1:)
JMODEM R <filename.typ> ( Receives a file from COM1:)
JMODEM S1 <filename.typ> ( Sends a file to COM1:)
JMODEM R1 <filename.typ> ( Receives a file from COM1:)
JMODEM S2 <filename.typ> ( Sends a file to COM2:)
JMODEM R2 <filename.typ> ( Receives a file from COM2:)
After version 1.05, JMODEM supported communications adapter
ports 1 through 4.
In a batch file, <filename.typ> may be a substitution
character.
JMODEM S2 %1 ( Sends a file to COM2:)
JMODEM R2 %1 ( Receives a file from COM2:)
- 4 -
JMODEM Protocol Page 5
- 5 -
JMODEM Protocol Page 6
Setting up a Communications Program
External File-Transfer Protocol.
On my system, TELIX resides in the C:\TELIX directory. A
copy of JMODEM.COM is also in that directory. TELIX passes
the filename as the %3 parameter. Therefore the contents of
JUP.BAT is:
C:\TELIX\JMODEM S1 %3
The contents of JDOWN.BAT are:
C:\TELIX\JMODEM R1 %3
If I wished to receive in the "batch" mode, I could make a
file like this. Notice that some communications programs do
not allow multiple file names. Note that the comments "!"
are NOT ALLOWED in a DOS batch file.
:DO_LOOP ! Return here
IF "%3" == "" GOTO DONE ! More parameters?
C:\TELIX\JMODEM R1 %3 ! Execute JMODEM
IF ERRORLEVEL 1 GOTO DONE ! Abort on error
SHIFT ! %4 becomes %3
GOTO DO_LOOP ! Continue
:DONE ! Exit batch file
If you do not know what "%" parameters are used to pass the
file name, all you have to do is make a "dummy" batch file
that contains the following:
@ECHO OFF
ECHO %1
ECHO %2
ECHO %3
ECHO %4
ECHO %5
PAUSE
When this is executed, you will see something like this:
1200
1
FILENAME.TYP
ECHO is off
ECHO is off
Strike a key when ready . . .
The first line contains "1200" which is the baud rate. This
means that the %1 parameter contains the baud rate.
The second line contains "1" which is the communications
adapter port being used. This means that the port is being
passed as the %2 parameter.
- 6 -
JMODEM Protocol Page 7
The third line contains "FILENAME.TYP" which is the file
name. This means that the file name is being passed as the
%3 parameter.
The fourth and fifth lines contain nothing to echo so DOS
replies the current state of the echo function which is
"off".
PCPLUS handles the file name passing a little bit different.
If I execute the same "dummy" batch file from the PCPLUS
directory, the response is:
FILENAME.TYP
ECHO is off
ECHO is off
ECHO is off
ECHO is off
Strike a key when ready . . .
This shows us that PCPLUS passes the file name as the first
parameter and there are no other parameters. However, If I
put more parameters on the command line within PCPLUS, they
will get sent to the batch file. The response is:
FILENAME.001
FILENAME.002
FILENAME.003
FILENAME.
ECHO is off
Strike a key when ready . . .
Therefore PCPLUS allows up to four file names to be passed
providing there's room on the command line.
Notice that these two communications programs check the
default directory for the external protocol batch file
FIRST! Therefore you must make certain that there are no
other similarly-named batch files in the current directory
or within the current path. Failure to do so will cause the
improper execution of the wrong batch file. Lets say that
the path was "C:\DOS;C:\TOOLS;C:\PCPLUS;C:\TELIX;C:\QMODEM".
If you named all your JMODEM external protocol batch files
with the same name, and you were attempting to use an
external file transfer protocol from QMODEM, the batch file
designed to operate with PCPLUS would be the first one
"found" and executed since the search-path will search the
\PCPLUS directory before the \QMODEM directory. You prevent
the execution of the incorrect batch file by calling them
slightly different names.
When setting up external protocols, remember to configure
the communications program so that it prompts you for the
file names. Unlike some protocols, JMODEM does not transfer
- 7 -
JMODEM Protocol Page 8
the file name. You can use any file name that you wish. You
must pass the file name to JMODEM since it must know the
name of the file being transmitted or received. There are no
defaults.
- 8 -
JMODEM Protocol Page 9
Setting up a BBS System
External File-Transfer Protocol.
If you are running a WILDCAT! bulletin board, the external
protocol files can be set up like this:
(JUP.BAT)
CD D:\WILDCAT\PROTOCOL
IF EXIST TRANSFER.BAD DEL TRANSFER.BAD
JMODEM R1 %3
IF ERRORLEVEL 1 GOTO END
COPY %3 %4
:END
DEL %3
(JDOWN.BAT)
CD D:\WILDCAT\PROTOCOL
IF EXIST TRANSFER.BAD DEL TRANSFER.BAD
JMODEM S1 %3
IF ERRORLEVEL 1 GOTO BAD
GOTO END
:BAD
COPY ALL.OK TRANSFER.BAD
:END
There are many variations available. Since WILDCAT! supports
batch-mode downloading, you could set up the batch file like
this:
(JDOWN.BAT)
CD D:\WILDCAT\PROTOCOL
IF EXIST TRANSFER.BAD DEL TRANSFER.BAD
:DO_LOOP
IF "%3" == "" GOTO END
JMODEM S1 %3
IF ERRORLEVEL 1 GOTO BAD
SHIFT
GOTO DO_LOOP
:BAD
COPY ALL.OK TRANSFER.BAD
:END
WILDCAT! checks the \PROTOCOL directory to see if the file
TRANSFER.BAD has been created. If it exists, it announces
that the file transfer has failed. It also announces "Error
with external protocol .. ". It does this when, in fact,
WILDCAT! has made an error itself. In many cases WILDCAT!
will "find" the file TRANSFER.BAD when it DOES NOT EXIST! In
spite of this bug, WILDCAT! is one of the most reliable BBS
systems supporting external protocols.
When setting up batch files remember that there is also a
bug in all DOS versions. The "IF ERRORLEVEL " statement does
- 9 -
JMODEM Protocol Page 10
NOT test the actual value of ERRORLEVEL! Instead it checks
to see if the returned value is EQUAL or GREATER than the
tested value. If you were to put the statement:
IF ERRORLEVEL 0 GOTO GOOD
.... in a batch file, the execution would ALWAYS branch to
label "GOOD" regardless of the actual ERRORLEVEL returned!
More about bugs when we get to the "BAD BBS" section towards
the end.
JMODEM does not require any information about handshaking.
It will look at the modem port and figure out for itself
what to do.
In the event that the modem carrier is lost, JMODEM will
abort. Since JMODEM only checks the modem port occasionally,
it may take several seconds to abort when the carrier is
lost. It is impossible for a user to get at the DOS level
through JMODEM. Do NOT use the CTTY command in the external
protocol batch files. JMODEM returns ERRORLEVEL 1 if there
was any error in transmission or reception. It returns
ERRORLEVEL 0 (no error) otherwise. It does not delete files
that have been partially received although it properly
closes them. The system operator can arrange the batch files
to delete them if required.
When JMODEM attempts to create a file that already exists it
can't ask the user if the old one should be deleted since
the user is probably not in a terminal program at the time.
Therefore, JMODEM renames the other file to <filename.OLD>
and creates the new file. In the event that <filaname.OLD>
exists, it is deleted before the rename operation occurs.
If you don't know what parameters are being sent to external
protocols, you can make a dummy batch file to check them
using the DOS's echo command just as explained in the user
interface previous to this "BBS" section. You can't see the
parameters being echoed from a remote terminal. You must be
present at the BBS board terminal to test those parameters
unless you modify the dummy command file like this:
@ECHO OFF
ECHO %1>COM1
ECHO %2>COM1
ECHO %3>COM1
ECHO %4>COM1
ECHO %5>COM1
If you find that your system passes the file name as %3,
your "upload" (receive) batch file would contain this:
JMODEM R1 %3
- 10 -
JMODEM Protocol Page 11
Your "download" (send) batch file would contain this:
JMODEM S1 %3
In these examples, it is assumed that you are using
communications adapter port "1".
- 11 -
JMODEM Protocol Page 12
The BAD BBS
Problem.
Believe it or not, there are several very fine running BBS
systems in use that do not properly handle external proto-
cols. MS-DOS provides the proper mechanism for loading and
executing "child" programs from within the "parent"
programs. This is function 4BH of the "DOS" INT 21H DOS
interface. Instead of using this function, these poorly-
behaved programs perform the external file-transfer protocol
in the following (or similar) manner:
(1) Make a DOS call to find the file-size of the
external file-transfer protocol.
(2) Free up an array of memory from "string-space"
within the program that is large enough to copy the external
file transfer contents into it. As assumption about the
data-space required by the external file transfer program is
made based upon the "block-size" information that has been
entered during configuration.
(3) Loads the file into string-space memory.
(4) If its an ".EXE" file, ignore the header.
(5) CALL the first byte of code!
If JMODEM is run in this environment, it WILL crash
the system. JMODEM assumes that it has been placed in memory
by MS-DOS and that an entire segment (64k) is available to
run. JMODEM uses two buffers that are almost 32k in length!
One of the buffers is used to support data compression and
expansion. The other is used for the interrupt buffer.
If you have such a BBS system and you wish to run JMODEM,
you can make a simple modification to the source-code, and
re-compile to produce a version which is a bit slower to
initialize and exit, but is guaranteed to leave all memory
and registers EXACTLY as they were when JMODEM got control.
This is done by saving and restoring all registers.
Additionally, any data space that will be modified is copied
to a file called VIRTUAL.MEM, then restored from that file
just before JMODEM exits.
You modify the source-code by finding the "BAD_BBS" equate
near the beginning of the file. This is normally set to
"FALSE". You set this to "TRUE". Then you recompile in the
following manner:
MASM JMODEM;
LINK JMODEM;
EXE2BIN JMODEM.EXE JMODEM.COM
DEL JMODEM.EXE
- 12 -
JMODEM Protocol Page 13
Do NOT attempt to execute the ".EXE" version. You must
change JMODEM to a ".COM" file. If you do not have
EXE2BIN.COM to make the change, you can use DOS's DEBUG to
do the same thing. You do it this way:
F:\DEV> debug jmodem.exe ; DOS command line
-rcx ; Examine CX register
CX 1239 ; Debug says the size was 1239
:
-h 1239,100 ; Calculate 1239H - 100H
1339 1139 ; Sum = 1339H, dif = 1139H
-rcx ; Examine register again
CX 1239 ; Is 1239H
:1139 ; Change to 1139H
; .. subtract 100H
-njmodem.com ; Name new SAVE file name
-w ; Write to file
Writing 1139 bytes ; Debug prompts
-q ; Exit
F:\DEV> ; Back to DOS
When you use this version of JMODEM, it will take a little
while longer to load and exit because it must write a 64k
block of memory to a file and read / delete in upon exit.
- 13 -
JMODEM Protocol Page 14
When things don't work!
The early versions of JMODEM assumed that it was being
properly loaded either by COMMAND.COM, the resident command
processor, or by a "parent" process that properly executes
the DOS function 1BH (the EXEC function). Much to my
surprise, I found that much BBS system software is not
written properly. Starting at version V1.10, I included the
"BAD_BBS" routines to help overcome some of the loading
problems that these BBS systems have. In some cases this
work-around was successful and in others it was not. In
version V1.13, I included some tests that verify whether or
not JMODEM has been loaded properly. Instead of crashing the
system, JMODEM now prints an error message and exits. These
error messages can help you find out what the problem is
and, hopefully, obtain a solution.
Presently, when JMODEM is loaded one of the first things it
does is make a DOS call to give up all memory except that
which contains the code. If DOS returns an error, it means
that JMODEM was not loaded properly and therefore doesn't
own any memory to give up! If an error message appears
telling you that JMODEM doesn't own any memory, you must
contact the writer of your BBS system software to obtain a
version that has this bug fixed. There will be no way to
execute JMODEM in this kind of environment without risking
serious system crashes.
The next thing JMODEM does is make a DOS call, requesting
64k (-1) bytes of memory for its necessary buffer space. If
this DOS call fails, a message is printed stating that there
is not enough memory available for JMODEM. In this case, you
simply reconfigure your BBS software to provide enough
memory for the external protocol. On some BBS systems, this
is done by defining "block-size". Generally, you just
specify the largest number that your BBS software will
accept and therefore force the BBS system software to
allocate a large block of memory for the external protocol.
Although the code size of JMODEM is small (around 4k), it
requires just as much memory as other external protocols.
The memory is used for three major buffers:
(1) Data buffer 8198 bytes
(2) Encode/decode buffer 32,767 bytes
(3) Interrupt buffer 20,000 bytes
These buffers are put in a separate segment so a wild bit-
stream input cannot cause a system crash. The index used for
addressing memory in the interrupt buffer simply wraps
around past 64k, back to zero. Of course you get data errors
when this happens, but no crash, and if the incoming bit-
stream ends before a time-out, the error is recoverable.
When satellite links lose lock, the result is usually a 20
to 30 second burst of noise (random bit-stream). At 9600
- 14 -
JMODEM Protocol Page 15
baud, you can easily overflow a buffer if it is not large
enough or is not allowed to wrap. Alternative methods are to
limit the size of the buffer and check the limit every time
a byte is put in the buffer. JMODEM doesn't do this for two
reasons. The first is the increased software overhead (the
check must be made for every byte in the interrupt service
routine) and the second is that you may be waiting for an
ACK. JMODEM always preserves the last byte in the buffer so
that, even with a noisy reverse-channel, the ACK/NAK can be
extracted.
These are the error messages and what they mean.
JMODEM error message:
Specified file "" not found
This means that no file name was passed to JMODEM on the
command line during a download.
JMODEM error message:
Specified file "\D:PATH\FILENAME.TYP" not found
This means that an incorrect file name was passed to JMODEM
on the command line during a download.
JMODEM error message:
Specified file "" Can't be created.
This means that no file name was passed to JMODEM on the
command line during an upload.
JMODEM error message:
Specified file "\D:PATH\FILENAME.TYP" Can't be created.
This means that an incorrect file name was passed to JMODEM
on the command line during an upload or:
o The path doesn't exist
o The drive doesn't exist
o Not enough file handles
Put FILES=40 in CONFIG.SYS and reboot
o Attempt to write to a network drive
If you are not networked, do NOT install SHARE
JMODEM error message:
File transfer aborted!
This is a normal abort. If the user didn't abort then the
active communications adapter port is not being passed to
JMODEM correctly.
- 15 -
JMODEM Protocol Page 16
JMODEM error message:
Modem carrier failed.
Modem either was not online or the user hung up during
protocol execution.
JMODEM error message:
Can't execute, no free RAM!
A poorly-written BBS system attempted to load the program as
a subroutine and execute it. Contact the BBS software
writer.
JMODEM error message:
This program was already loaded over resident code.
The system will probably crash!
A poorly-written BBS system just loaded JMODEM over its own
code!
JMODEM error message: Can't create file VIRTUAL.MEM
JMODEM error message: Can't write file VIRTUAL.MEM
JMODEM error message: Can't close file VIRTUAL.MEM
JMODEM error message: Can't open file VIRTUAL.MEM
JMODEM error message: Can't delete file VIRTUAL.MEM
When compiled with the BAD_BBS system conditional set to
"TRUE", JMODEM was unable to do the required file I/O
because something was screwed up by the BBS software or
there were not enough file handles available. Enter FILES=40
in CONFIG.SYS and reboot. This can also happen if SHARE is
installed and no network exists. Do NOT use SHARE if you are
not networked!
JMODEM error message:
DOS reports that JMODEM was improperly loaded and does not
own the memory it is using!
The BBS system software is either improperly configured or
improperly written for external protocols. Contact the
writer of the BBS system software.
JMODEM error message:
Not enough free memory for JMODEM to use!
The BBS system software is not properly configured to give
JMODEM the memory it requires to execute. Check the BBS
system software documentation and reconfigure.
If you have problems using JMODEM with your system, you can
call the PROGRAM EXCHANGE and leave a message You can also
test your communications program's external file-transfer
protocols by transferring files (hopefully uploading) to the
PROGRAM EXCHANGE. Currently there are hundreds of boards
- 16 -
JMODEM Protocol Page 17
that are using this protocol and the number is growing every
day. Most problems encountered are found to be caused by
incorrect file names being sent to JMODEM (the wrong "%"
parameters). A simple batch file to test these parameters
will go a long way towards solving the problems.
Richard B. Johnson
PROGRAM EXCHANGE
(303) 440-0786
Boulder Colorado
80303
- Finis -
- 17 -