Date   : Sat, 28 Jan 1984 12:05:21 EST
From   : Keith Petersen <w8sdz@brl>
Subject: MDM720 now available

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--