home *** CD-ROM | disk | FTP | other *** search
/ ftp.barnyard.co.uk / 2015.02.ftp.barnyard.co.uk.tar / ftp.barnyard.co.uk / cpm / walnut-creek-CDROM / BEEHIVE / COMMS / MEX4BEE.ARC / MEXNEWS.001 < prev    next >
Text File  |  1990-09-20  |  8KB  |  172 lines

  1.  
  2.             MEX Newsletter #001
  3.  
  4. Date:      05-09-84
  5. From:    Ron Fowler
  6. MEX rev: 1.00
  7.  
  8. This is the first in what will probably be a series of informative notes for
  9. the MEX communications program.  These newsletters will provide bug fixes,
  10. tips, applications information, etc. for users of MEX.
  11.  
  12. In order to avoid the daily-revision syndrome that was such a problem for
  13. users of MDM7, important bug fixes will be provided in the newsletter whenever
  14. possible, in a form useable in a READ file.  The hitherto undocumented
  15. POKE command will be used to install patches; you can use the CLONE command
  16. to save the patched program.
  17.  
  18. ------------------------------------------------------------
  19.  
  20. These minor bugs have been found in the initial release of MEX: 
  21.  
  22. 1) Certain commands result in screen output that contains a graphics or rev-
  23.    erse video character; these commands are typically those which list key-
  24.    words out of a table (the '?' command, "STAT ?", "HELP ?", etc).  These
  25.    keywords have the high-bit set in the last character of the keyword, and
  26.    MEX doesn't reset that bit.
  27.  
  28. 2) For Alternate Long Distance Numbers: if an ALDN number is greater than
  29.    12 characters, and the ALDN is specified on the command line, (eg,
  30.    "[MEX] A0>>CALL <805-555-1212"), MEX misses any characters in the ALDN
  31.    number beyond the 12th.
  32.  
  33. The following patch sequence will fix both problems.  Use your text editor to
  34. copy the following 8 lines into a file (say, MEXFIX.MEX), then use the READ
  35. command to execute it ("READ FIXMEX").  Make sure your MEX is still functional,
  36. then use CLONE to save the fixed copy to disk (e.g., "CLONE NEWMEX.COM").
  37.  
  38.  
  39. POKE $0E6A $CD $B3 $14 $D8
  40. POKE $0E6E $3E $0C $EB $CD
  41. POKE $0E72 $01 $46 $EB $C3 $DE
  42. POKE $0E77 $12
  43. POKE $0E78 $E6 $7F $21 $DC $52 $C3 $89
  44. POKE $0E7F $43
  45. POKE $12DA $C3 $6A $0E
  46. POKE $4386 $C3 $78 $0E
  47.  
  48.  
  49.  
  50. This patch will be incorporated in the next revision of MEX (probly 1.01).
  51.  
  52. ------------------
  53.  
  54. A number of users have reported that MEX disconnects them when any of the
  55. exit-to-system commands (BYE, CPM, EXIT, SYSTEM) are entered.  The command
  56.  
  57. POKE $0168 $0C9
  58.  
  59. will fix that problem for most (again, CLONE your MEX to make the change
  60. permanent).  This problem exists with several overlays, and relates to two
  61. entries in the overlay jump table, usually called JMP$GOODBYE and JMP$DISCON
  62. in MDM overlays (GOODBV and DISCV is MEX overlays).  MEX assumes that the
  63. JMP$DISCON routine disconnects the phone; it is called on an X secondary
  64. command or from the DSC command.  JMP$GOODBYE is called just prior to exiting
  65. MEX and re-entering CP/M, providing a way for the overlay (if it needs to)
  66. to "clean up" before CP/M gets control back.  Apparently MDM7 does not call
  67. these routines in the same way, since several overlays have both of these
  68. entries pointing to disconnect code.  Hence, an exit always disconnects.
  69.  
  70. I believe that these overlays are technically in error; JMP$GOODBYE should
  71. have no reason to disconnect the phone.  Problem is, Irv Hoff never documented
  72. the MDM overlay entry points (at least, as far as I know), so I can't be
  73. sure of his intent.  In any case, I'd recommend that the offending overlays
  74. be modified; this would make the change permanent (otherwise, the above POKE
  75. must be executed each time a new MEX is generated).
  76.  
  77. ------------------------------------------------------------
  78.  
  79. CIS protocol notes:
  80.  
  81. I didn't mention in the features list in -READ.ME (or in any of the announce-
  82. ments that I sent out) that MEX is capable of file exchange with Compuserve,
  83. using their "A" protocol.  Do "HELP CIS" for a little more information about
  84. this feature.  If you don't use Compuserve and resent having valuable buffer
  85. space taken up by Compuserve code, do "HELP COLD" for information on how to
  86. remove the Compuserve code altogether, and reclaim the space for buffers.
  87.  
  88. Some notes on file-append:
  89.  
  90. Also not mentioned in the announcements was the "A" secondary option for the
  91. T, E and L commands: this one lets you append to the end of an existing term
  92. file (do "HELP APPEND" for more information on the "A" option).  I should
  93. point out that some text editors write out files that are not compatible with
  94. the way MEX does a file-append.  The algorthm used by MEX allows a fast
  95. seek-to-end, and works like this:
  96.  
  97.     1) seek last physical record
  98.     2) scan backwards until end-of-file mark found (1AH)
  99.     3) scan backward until the first non-1A is found; this is
  100.        the last file character
  101.     4) copy any previous characters in the record to the capture buffer
  102.  
  103. This should always work for files created by MEX; certain text editors, how-
  104. ever, put a single 1A at the end of file, followed by random characters.  If
  105. one of these random characters is a 1A, MEX will find a false end of file 
  106. (after the real end), and newly-appended text will be "invisible".
  107.  
  108. Other editors do not put an end-of-file mark in the file if the text ends
  109. on an even 128-byte boundary (ED.COM does this).  This too will cause problems
  110. with the 'A' option.
  111.  
  112. Thus, unless you're sure your text editor legitimately writes the end-of-file
  113. mark (and pads the last sector with EOF marks) it's best to use the 'A' option
  114. only with files created by MEX.
  115.  
  116. READ files:
  117.  
  118. The documentaton doesn't mention it, but if you specify a READ file without
  119. a filetype (eg, "READ CALLJOE"), MEX will assume a filetype of "MEX" (in fact,
  120. a file named "CALLJOE" can't be found by MEX for this reason).
  121.  
  122. ------------------------------------------------------------
  123.  
  124. It might not be clear from the documentation, but you can make your phone
  125. numbers and keystring definitions a permanent part of MEX.  Simply define
  126. the numbers you frequently use with the PHONE command (or LOAD a file from
  127. disk), define your keystrings (or LOAD them), the do "CLONE <filename>".
  128.  
  129. You can, at any time, change the phone numbers or keystrings and re-CLONE;
  130. MEX may be CLONEd any number of times.
  131.  
  132. ------------------------------------------------------------
  133.  
  134. Misc. gotcha's:
  135.  
  136. 0) In spite of what the documentation says, MEX will not run "out-of-the-box";
  137. the overlay file must be installed first.  This was due to a change that was
  138. made just prior to release.
  139.  
  140. 1) It has been brought to my attention that, if you use the CLONE command with-
  141. out a filename, MEX will write a filename of all blanks as the CLONE file.
  142. Be sure to specify a name to the CLONE command; I'll make sure that the next MEX
  143. does not allow all-blank filenames.
  144.  
  145. 2) Another problem is that, if you specify a drive name with the filename for
  146. the 'R' or 'S' commands (send/receive/Christensen protocol), MEX ignores
  147. the command altogether. For now, just forego the drive name, and log into
  148. the drive you want to send from or receive to.  This, too, will be repaired
  149. in the next revision (this doesn't affect batch transmissions under the 'B'
  150. secondary option).
  151.  
  152. 3) Some users have had problems with keystring memory becoming corrupted; I'm
  153. looking into the problem, but have not been able to corrupt my keystring
  154. memory.  The most frequent complaint is that these garbage keystrings can't be
  155. deleted with the KEY command. If you have this problem, do this:
  156.  
  157.     [MEX] A0>>COLD
  158.  
  159. This will erase your keystrings (*and* your phone numbers!), and allow you
  160. to start over.  Nothing else will be disturbed.
  161.  
  162. 4) The third line of the HELP file under LOAD (and SAVE) specifies an illegal
  163. example for saving a phone number file:
  164.  
  165.     SAVE C:NEWPHONE.NUM
  166.  
  167. (phone number files must have a filetype of "PHN").
  168.  
  169.  
  170.  
  171. -------------< End of MEX newsletter #001 >--------------
  172.