w8sdz%brl@sri-unix.UUCP (01/28/84)
From: Keith Petersen <w8sdz@brl>
MDM720, the latest version in the MODEM7 series, is now available
on SIMTEL20 in the MICRO:<CPM.MODEM7> directory (and temporarily
on MIT-MC in the FJW; directory). The file names are:
SIMTEL20 MIT-MC
MDM720.ASM MDM720 ASM
MDM720.COM MDM720 COM (in ITS-binary format on both hosts)
MDM720.HEX MDM720 HEX
MDM720.MSG MDM720 MSG
M7NM-5.ASM M7NM 5ASM (phone number overlay - see note below)
NOTE: This program when assembled is 69 sectors long. Use this figure
when merging the appropriate overlay file for your computer via DDT,
etc. (Most of the overlays were written when MDM7xx.COM was only 66
sectors and the example included in each says to store 66 sectors.)
For MDM720 use: SAVE 69 MDM720.COM.
NOTE: If using the phone number overlay to change the phone library
numbers, be sure to use: M7NM-5.ASM (Previous versions of M7NM will not
work with this new version, as the file transfer buffer is now optional
length, nominally set for 4k and there is an option to show/not show
the both the decimal and HEX record count.)
Most users will not need the lengthy (154k) source code. Just get
MDM720.COM and then check one of the associated overlay programs to
obtain the overlay for your particular computer. Merge that with
MDM720.COM according to the instructions near the start of the overlay
file, using DDT.COM, etc. (See above note relative to saving 69
sectors. STAT.COM would then show 138 records for 18k.)
CHANGES FOR MDM720
------------------
Changed the printer routine - a number of people had problems with
the printer working properly. It now works correctly for several who
previously had problems. Increased the stack depth. Now have the
ability to select "SHOWHEX" via DDT with a byte two ahead of NUMBLIB.
This requires using M7NM-5.ASM if you want to change the telephone
number library.
0CFEH - HEXSHOW 00 = do not show hex record count
FF = show both hex and decimal count
0CFFH - SAVSIZ 20 = 4k file transfer buffer size
40 = 8k file transfer buffer size
80 = 16k file transfer buffer size
0D00H - NUMBLIB (start of telephone number library)
- Irv Hoff
CHANGES FOR MDM719
------------------
Fixed error in GETACK routine which prevented the robust improve-
ment (added in MDM716) from working. Changed ACKNAK to NO so default
will require valid NAK rather than non-ACK. This is part of the robust
improvements, not because of any special ArpaNet requirement. Changed
SHOWHEX to true for distribution version so users would have HEX and
DECIMAL reporting while transferring files (most users have told me
they prefer to see both). Changed PMMI dialing pulse default to 10pps
which most exchanges will accept. (This can be set to other pulse rates
in the user overlay.) - Keith Petersen, W8SDZ
CHANGES FOR MDM718
------------------
Code added to the auto-dial routine for the new Anchor 300/1200
modem which are selling at discount houses for $270 or so. Computer now
beeps continuously anytime a connection is made to attract the operator's
attention. Made the file transfer buffer length separate from that of
the ASCII capture buffer (which remains 16k, one file-extent). Although
the file transfer buffer has been 16k for well over a year, some of the
newer floppy disk systems are quite slow and timeout errors could occur.
The file transfer buffer size is set by default to 4k (32 records, 20H).
It can be set at assembly time if using the entire MDM720.ASM file, or
can be set in a few seconds with DDT by changing byte 0CFFH. The number
library is now fully automatic to insure it always starts on a new page
(such as 0D00H) regardless how much the auto-dial section is altered.
Now responds to either "single digit" result codes (some Hayes Smartmodem
users leave SW2 set that way) as well as the normal "verbose" result
codes.
To change the file transfer buffer size via DDT, change byte 0CFFH:
10 (hex) = 16 records = 2k
20 (hex) = 32 records = 4k
40 (hex) = 64 records = 8K
60 (hex) = 96 records = 12k
80 (hex) = 128 records = 16k
(then SAVE 69 MDM.COM, etc.)
CHANGES FOR MDM717
------------------
MDM717 allows characters with parity bit set to be properly handled
during propagation overruns after an X-off. This occurs during a "save
to disk" after the disk buffer fills. (This problem was noticed on Com-
puserve which sends some characters with the parity bit set.)
The disk buffer size was restored to 16k. This is the length of
"one file extent". Even slow floppy disks can store 16k in a reason-
able amount of time. This should remain 16k for distribution copies of
the source code although it can be easily changed to suit the individual
user's own preference. (It could even be lengthened to 32k if you like
fewer disk operations. This would make the printer buffer proportion-
ally smaller but most printers are so fast the buffer is rarely filled
in any case.)
Fixed a stack problem introduced in v716 in the "V" flag routine to
allow the user to show ASCII characters on the CRT during a file trans-
fer.
Fixed the "L" Logon feature so it should be consistent. At times
it would run away without waiting for the echo characters, thus not cor-
-rectly displaying the Logon message.
Restored the ACKNAK feature developed for the exclusive use of the
ARPANET networking group. When set normal ("YES") it resends a disk re-
cord after any NON-ACK character is received. This has been the normal
configuration for all RCPM systems using the XMODEM file transfer pro-
gram. When set "NO" for ARPANET use, it resends a record only after a
NAK has been received. Other characters are ignored. Some systems will
resend a NAK after a 10-second TIMEOUT. This slows things considerably,
which allows the main frame time to recover if busy. This tends to run
the phone bill higher for RCPM use, but is necessary for ARPANET to pre-
vent aborting the file transfer too quickly if the main frame is busy.
If a normal TIMEOUT sequence does attempt to abort the transfer with the
ACKNAK equate set to NO, it will ask if you want to try again or abort.
(RCPM systems would have already timed completely out with 10 consecutive
errors, making the question worthless and misleading. ARPANET does not
have a similar feature, and the user can manually force the transfer to
continue.) - Irv Hoff
--end--