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.003 < prev    next >
Text File  |  1990-09-20  |  7KB  |  184 lines
  1.  
  2.                 MEX Newsletter #003
  3.  
  4. Date:      05-27-84       From:  Ron Fowler               MEX rev:  1.00
  5.  
  6.  
  7.                             New Patch File
  8.                        Correspondence Information
  9.                          Hi-Speed File Transfers
  10.                            Upcoming Release
  11.                              MEX Overlays
  12.                       Jury Still Out on Dial-Abort
  13.  
  14.  
  15. This is the third in a series of (hopefully) informative notes for users of
  16. the MEX communications program.  These newsletters will provide bug fixes,
  17. tips, applications information, etc.
  18.  
  19. ------------------------------------------------------------
  20.  
  21. New patch file
  22.  
  23. Many of you have probably noticed how sluggish MEX is during file transfers,
  24. often taking 30 or 40 seconds just to get started (also very noticeable dur-
  25. ing batch transfers).  Well, it seems the timing constants in MEX are a off
  26. by a factor of three!  The following HEX file patch will repair that, and
  27. bring your revision level up to 'C' (no, I didn't skip B -- it just didn't
  28. get distributed very far).
  29.  
  30. This patch also repairs a bug that several overlay writers have reported:
  31. after implementing the NEWBDV overlay extension, numbers entered on the
  32. command line (ie, not called from the phone library) would cause a random
  33. baud rate to be set.
  34.  
  35. Incidently, this patch repeats the A patch in Newsletter #002 -- if you
  36. haven't already installed that one, you don't have to worry about installing
  37. it first.  If you have installed it, this one just writes over the same
  38. code that the first one generated, so it won't hurt anything.
  39.  
  40.  
  41. Here's the patch code:
  42.  
  43. :0B0CF5003EFF323853215C53C3FF1256
  44. :100E6A00CDB314D83E0CEBCD0146EBC3DE123AD417
  45. :0F0E7A0052B7C4EA31F1F5E67F21DC52C3894358
  46. :0152D40000D9
  47. :0312DA00C36A0ED6
  48. :03438100C3780EF0
  49. :010ED70043D7
  50. :01130C0000E0
  51. :0312FC00C3F50C2B
  52. :020EA600D0007A
  53. :020EAF000D0034
  54. :0000000000
  55.  
  56.  
  57. Just 'clip' the above lines from this file with your text editor into
  58. a file named MEXFIX.HEX, and do this:
  59.  
  60.         MLOAD MEX.COM=MEX.COM,MEXFIX
  61.  
  62. (make sure you've saved a copy of MEX before making the patch, however,
  63. in case something goes wrong).
  64.  
  65. I've been using the timing patch for the last week or so, and it makes MEX a
  66. lot more responsive, but since it changes the overall timing for the entire
  67. program, there is always the possibility of a side-effect.  If this patch
  68. causes any weird problems (a symptom of such a side-effect would be something
  69. that happens three times as fast as it should), please let me know.
  70.  
  71. One final note: since the patch area within MEX was entirely consumed by
  72. previous patches, this one had to go at the top of the overlay area.  This
  73. shouldn't be a problem, unless you use an overlay that uses every available
  74. byte, something I think is pretty unlikely (if you're using the standard MXO
  75. Smartmodem overlay, the top area is definitely free).
  76.  
  77. ------------------------------------------------------------
  78.  
  79. Correspondence:
  80.  
  81. The Fort Atkinson BBS is back online 24 hrs (except when in use locally)
  82. at 300 and 1200 baud.  This is now the best way of reaching me with a question
  83. or comment (outside of Arpanet); since my Compuserve access is through another
  84. user's account, I log in on CIS as seldom as possible (it's also a long
  85. distance call).  I've also been logging in a lot less frequently on the SYSOP
  86. system in Michigan ... (it's always busy!).
  87.  
  88. Our overlay collection is less than complete (even some of the new MXO over-
  89. lays are not present there yet).  We hope to have a complete collection on-
  90. line by early June, of both MXO and M7 overlays.
  91.  
  92. Fort Fone File Folder: (414) 563-9932 ... should answer on 1st ring (made
  93.                        busy when in use locally)
  94.  
  95.  
  96. ------------------------------------------------------------
  97.  
  98. High-speed transfers:
  99.  
  100. I've been using MEX locally for transfers between two computers connected
  101. through an RS-232 link.  File transfers at speeds of 9600 and 19200 are
  102. possible, with the following guidelines noted:
  103.  
  104. 1) If one computer has a faster CPU clock speed than the other, it can receive
  105.    at 9600 or 19200 without problems (assuming no extraordinary delay in 
  106.    the overlay modem I/O routines).
  107.  
  108. 2) The receiver should use the 'Q' mode ('quiet': no status messadpees
  109.    (BALANCE OF 2 TRASHED IN TRANSMISSION)
  110.  
  111. 3) It's not generally a good idea to view either received or transmitted
  112.    characters at the receiving end, regardless of clock speed (i.e., avoid use
  113.    of the V, S and R secondary commands at the receiving end).
  114.  
  115. 4) Batch file transfers will work much better with the above speed patch.
  116.  
  117.  
  118. ------------------------------------------------------------
  119.  
  120. Forthcoming release:
  121.  
  122. I hope to start work on MEX revision 1.10 within the next week or so (pend-
  123. ing completion of a couple of deadlined projects I'm involved in).  The new
  124. release will hopefully accomplish the following:
  125.  
  126.     - Incorporate all patch fixes
  127.     - Fix a couple of minor annoyances (like control-C abort not
  128.           working at times)
  129.     - Add some hooks requested by users for special overlay access
  130.     - Add a couple of features 
  131.  
  132. If I can get to it, the new release should be out sometime in the first
  133. half of June (unless I get carried away adding stuff).
  134.  
  135. ------------------------------------------------------------
  136.  
  137. MEX overlays
  138.  
  139. MEX overlays are coming in at an astonishing rate; turns out there is some
  140. confusion about just where a MEX overlay differs from an M7 overlay, so
  141. I thought I'd clarify that a little.
  142.  
  143. MEX overlays do not call the MDM7 jump table (the one with JMP$ILPRT,
  144. JMP$INLNCOMP, etc) .... instead, they use the MEX service processor.  The
  145. reason for this is facilitate my long-term plan to condense the overlay
  146. format (say around MEX 2.0, perhaps).  I should be able to take an MXO
  147. overlay and turn it into an MX2 overlay in a matter of minutes, with
  148. little chance of buggifying the code in the process.
  149.  
  150. In addition, I'd prefer that MXO overlays use the simpler label names
  151. I've employed in the PM and GB overlays (although I should have mentioned
  152. this much sooner: quite a number of re-released M7 overlays have the old
  153. label names intact).
  154.  
  155. At any rate, the idea is that if I impose a new overlay structure in the
  156. future, the burden of changing the overlays should fall on me, not the
  157. user (*especially* if MEX2 is a commercial product, something I'm still
  158. fighting with myself about); the MXO format makes that change somewhat
  159. easier.
  160.  
  161. ------------------
  162.  
  163. Dial-abort problem:
  164.  
  165. A lot of people have mentioned that they can't abort an in-progress DIAL
  166. command.  I haven't been able to duplicate that here (abort always works
  167. fine for me).  If anyone has any idea what's causing this problem, please
  168. let me know.
  169.  
  170. There are a number of places within MEX that don't check the console for
  171. an abort (mostly within file transfers); also some screen displays that
  172. don't check for a ^S pause.  Hopefully, I'll zap all these when I do the
  173. new release ....
  174.  
  175.  
  176. ------------------
  177.  
  178. Special thanks here to Cliff Harrison for re-formatting the DOC files;
  179. they were pretty ugly in their original state (I rushed them out in about
  180. a day or 2).  The new format is a welcome change; I'll make sure they
  181. stay maintained this way.
  182.  
  183. ----------------------------< MEXNEWS.003 >------------------------------
  184.