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 / CPM / MEX / MEXNEWS.004 < prev    next >
Text File  |  2000-06-30  |  10KB  |  234 lines
  1.  
  2.                 MEX Newsletter #004
  3.  
  4. Date:      07-03-84       From:  Ron Fowler               MEX rev:  1.00
  5.  
  6.                 Batch bug Fix
  7.                MEX 1.10 pushed back
  8.             More on Fort Fone File Folder
  9.              Useable operating systems
  10.                M7 overlay notes
  11.                  HELP bug
  12.                 ALDS support
  13.                   Support 
  14.  
  15. This is the fourth in a series of (hopefully) informative notes for users of
  16. the MEX communications program.  These newsletters will provide bug fixes,
  17. tips, and applications information.
  18.  
  19. ------------------------------------------------------------
  20.  
  21.  
  22. Batch Bug Fix
  23. -------------
  24.  
  25. The following bug is potentially quite serious; the patch should be in-
  26. stalled as soon as possible if you use batch file transfers.
  27.  
  28.                 -----
  29.  
  30. I've discovered a pointer calculation error in the batch file-lookup
  31. routine.  This affects batch receive (only), and is only a problem if
  32. the incoming batch file already exists on the disk.  In some circumstances,
  33. the existing file will be left on the disk, and the succeeding file in
  34. the directory will be erased and replaced with the incoming file.
  35.  
  36. To fix this, execute the following command, either from a READ file or
  37. by typing it in at command level:
  38.  
  39.         POKE $429A $3C $00 $C8
  40.  
  41. (and then, of course, use the CLONE command to create a new MEX).
  42.  
  43. MEX 1.10 / 2.0:
  44. ---------------
  45.  
  46. At the moment, I'm involved in a full-scale TurboDOS implementation, which
  47. is eating up most of my spare time.  Thus, I've had to push MEX 1.10 back
  48. a month or two.  Hopefully I'll be able to get back to MEX development in
  49. the next few weeks.
  50.  
  51. Contrary to rumor, MEX 1.10 will not be the commercial version hinted at
  52. in the MEX documentation. The 1.10 release will fix all known bugs and add
  53. a feature or two.
  54.  
  55.                <soap-box dept>
  56.  
  57. Speaking of a "commercial" version, I've been accused of "using the entire
  58. user community as a beta-test group in the eventual marketing of MEX".  Rather
  59. than let this accusation go unchallenged, I'd like to mention the futility
  60. of selling a program that I've already given away with no strings attached.
  61. I will definitely not charge anybody anything for a bug-fix release.
  62.  
  63. It is likely, however, that MEX 2.0 will be a commercial effort; I think the
  64. difference between MEX 2.0 and MEX 1.x will be as dramatic as that between
  65. MEX and MODEM7 (it would have to be to find any significant customer base).
  66. Among the things I'm considering for MEX2 are nested READS, full-blown
  67. interpreted READ files (with incoming string-analysis conditionals and
  68. success-codes returned by most commands), "background" printer support with
  69. adjustable left, right, top and bottom margins, optional terminal support
  70. (cursory x-y, insert/delete line, highlighting, etc), "server" mode, LBR
  71. and SQ support, and an "overlay" structure (which would allow most of the
  72. commands to be pulled out of the main program, shrinking it down to perhaps
  73. 10-14K).
  74.  
  75. Thus it would appear that MEX2 will require as much or more effort than
  76. MEX1.  If this didn't justify at least a small return for my development
  77. time, then I doubt if I would make the effort at all.
  78.  
  79.  
  80. Fort Fone File Folder:
  81. ----------------------
  82.  
  83. Our local RCPM system is now up on brand new hardware, running a 40MB hard
  84. disk (works out to about 36.5 MB after formatting).  Fort Fone is the best
  85. (and perhaps the only) way to get timely answers to MEX questions.
  86.  
  87. The MEX documentation incorrectly listed the number of FFFF.  The number
  88. is (414) 563-9932.
  89.  
  90.  
  91. Useable operating systems:
  92. --------------------------
  93.  
  94. I failed to mention in the original documentation that MEX does not run
  95. under CP/M 1.4 (I was surprised to find that there is still a significant
  96. CPM 1.4 user community!).  My apologies to anyone this inconvenienced.
  97.  
  98. In general MEX will run correctly under MP/M and TurboDOS, but requires
  99. that the modem be interrupt-driven with minimum input queue size of 134
  100. characters (single-tasking TurboDOS excluded).  I've written a TurboDOS
  101. overlay that uses the built-in COMM channels for I/O, but it's a little
  102. sluggish because of the overhead involved in the calling the O/S for modem
  103. status ... I'll be adding some hooks in 1.10 to make this work better.
  104.  
  105. MEX should work correctly under CDOS (later releases) ... there is a flag
  106. byte in MEXPAT (CDOSFL) that should be turned on under CDOS to prevent MEX
  107. from making a disk-parameter request (which is not supported by CDOS).
  108.  
  109.  
  110. M7 Overlay Notes
  111. ----------------
  112.  
  113. There are problems with a few MDM7 overlays when used with MEX.  Since I
  114. seem to be answering these questions over and over, I'll go over them here,
  115. and refer any future questions to this newsletter.
  116.  
  117. 1) After installing my overlay, when I go into terminal mode, I get the
  118.    message "modem overlay not installed".
  119.  
  120.    The problem is with the bit-status tests in the modem overlay.  I trapped
  121.    all seven in the un-installed MEX, figuring all overlays would at least
  122.    leave a "RET ! NOP ! NOP" in the associated jump table entries.  Not so.
  123.    To fix this problem, simply modify your modem overlay to make sure that
  124.    at least a "RET" is generated in any unused jumps.  These entries are
  125.    located as follows:
  126.  
  127.     012AH   (in-modem-control-port)
  128.     0134H   (out-modem-data-port)
  129.     013EH   (in-modem-data-port)
  130.     0148H   (mask-receive-ready)
  131.     014BH   (test-receive-ready)
  132.     014EH   (mask-send-ready)
  133.     0151H   (test-send-ready)
  134.  
  135. 2) Whenever I exit with the CP/M command, the modem disconnects.
  136.  
  137.    This one is a result of confusion between two overlay entry points.  The
  138.    routine jumped to by the JMP$GOODBYE vector (0168H, called GOODBV in MEX
  139.    overlays) should not disconnect the overlay -- this is the job of the
  140.    JMP$DISCONNECT entry (0165H, called DISCV in MEX overlays).  GOODBYE is
  141.    called expressly for overlays that need to "clean up" before returning
  142.    to CP/M, and is called immediately before exiting to the operating sys-
  143.    tem.  Some overlays use the same routine for both entry points, something
  144.    that MDM7 allows for some reason.  To fix this, change the JMP$GOODBYE
  145.    to point to a RET instruction.
  146.  
  147. 3) My overlay works fine, but when I enter a baudrate into the phone num-
  148.    ber library, it's ignored by MEX.
  149.  
  150.    Only MXO overlays are capable of changing baudrate from a phone library
  151.    entry (and then, only if the overlay author writes the code).  This fea-
  152.    ture uses a jump table entry present in MDM7 overlays, but implemented
  153.    only for the PMMI modem, called PBAUD.  If you'd like to implement this
  154.    feature, see the example code and notes in MXO-PMxx.ASM and MXO-GBxx.ASM,
  155.    both of which have this feature included.
  156.  
  157.  
  158. 4) The overlay works fine, but using <esc>-P in terminal mode, to turn on
  159.    the printer, doesn't have any effect.  The printer never outputs anything.
  160.  
  161.    The most common cause of this is a BIOS with list-status improperly NOT
  162.    implemented (no typo there, read on...).  A CP/M BIOS that does not im-
  163.    plement the list device status routine should always return A=0FFH (the
  164.    ready condition); many, however, return A=0 (not ready).  Thus MEX never
  165.    sees the printer as being ready, and never outputs characters.
  166.  
  167.    You can fix this by overlaying the LSTS vector in MEXPAT (located at 0D11H
  168.    within MEX) with the address of a replacement routine in your overlay.
  169.    For example, the following might be added to your overlay:
  170.  
  171.         PRTSTS: IN  PRPORT        ;input status port
  172.             ANI 80H            ;test ready bit
  173.             RZ            ;return A=0 if not ready
  174.             MVI A,0FFH        ;else return A=255
  175.             RET
  176.     ;
  177.             ORG 0D11H        ;patch the MEX vector
  178.             DW  PRTSTS        
  179.  
  180.  
  181. HELP bug
  182. --------
  183.  
  184. A minor bug has been reported with open HELP files: if you do a READ (or
  185. LOAD/SAVE) with an open HELP file, succeeding HELP commands get lost, and
  186. print out garbage.  To recover from this, simply use the LOG command to
  187. cause HELP to re-open its file with the next HELP command.
  188.  
  189.  
  190. ALDS Support
  191. ------------
  192.  
  193. Apparently, I neglected to mention in any of the documentation files that
  194. MEX supports Alternate Long Distance Service, up to a maximum of two such
  195. numbers (although, for some reason, it doesn't seem to work with the An-
  196. chor modem).  So I'll do it here.
  197.  
  198. To enter an ALDS number into your phone library, enter it as you would any
  199. other number, except that its name must be '<' (left arrow) or '>' (right
  200. arrow).  These two specially-named numbers may then be called out as a
  201. prefix to any other number (whether in the phone library or entered on the
  202. command line).
  203.  
  204. For example, let's say you access Sprint through the number 555-1234 and you
  205. also have MCI service available through 555-4321. Enter the numbers in
  206. the library this way:
  207.  
  208.         PHONE >=555-1234,,,,,99999   <=== include delays + user code
  209.         PHONE <=555-4321,,,,,88888
  210.  
  211. Now, to route any call thru Sprint, simply prefix with a '>'.  For example,
  212.  
  213.         CALL >808-555-99999
  214.         CALL >TECHCBBS
  215.         CALL <CONOGA        <<--- this one uses MCI
  216.     
  217. You can also enter numbers in the library with a "built-in" sprint code:
  218.  
  219.         PHONE TECHCBBS=<909-555-3333
  220.  
  221. Support
  222. -------
  223.  
  224. Finally, a short note about support for various overlays, machines, and so
  225. on.  I've gotten several requests from people to write overlays for specific
  226. machines, and some phone calls from people asking for help with debugging
  227. their overlays.  The latter I don't mind doing, as time permits (but *please*
  228. use the RCPM system instead of my voice line!); I don't have the time or
  229. inclination, however, to write custom overlays.
  230.  
  231.  
  232.  
  233. ----------------------------< MEXNEWS.004 >------------------------------
  234.