Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!floyd!harpo!seismo!hao!hplabs!sri-unix!erh%virginia@csnet-relay From: erh%virginia%csnet-relay@sri-unix.UUCP Newsgroups: net.micro.cpm Subject: none Message-ID: <16364@sri-arpa.UUCP> Date: Thu, 9-Feb-84 01:23:16 EST Article-I.D.: sri-arpa.16364 Posted: Thu Feb 9 01:23:16 1984 Date-Received: Wed, 8-Feb-84 09:32:13 EST Lines: 34 1 I have recently obtained MDM716 and I am gratified with its performance. I submit the following suggestions in hope of making the excellent thing better: 1. The overlay method of customizing the program is still too specific. Ideally, there should be two clearly defined overlays: -- an outer one containing all procedures for a given modem or modem setup. There would be one overlay for PMMI, another for Hayes, etc. This overlay should contain well isolated procedures to hang up the modem, send a break, etc. The way it is now, a Hayes user has to wade through all the PMMI stuff to find the relevant code (not mentioning the fact that the code for the other modems just sits there and uses the precious K's). To wit: Hayes can be told to hang up by dropping DTR, which is infinitely faster than sending the #$%! pluses, but the DISCONNECT stuff is buried too well for me to bother. That outer overlay should contain procedures to do all kinds of exotic things, such as change the baud rates, etc. Use flags to indicate which procedures are valid. -- an inner one dealing with the i/o hardware: sending and receiving characters from the modem. And please, have somewhat more general procedures. The functions to mask a status byte are cute, but too primitive. The guys using interrupts and BIOS bufferring of incoming characters would prefer to use a system or BIOS call to get/test for input characters. 2. The dialing procedures could be somewhat smarter. Use some way of separating the decription from the phone number. The way it is now, all digits get dialed out, including things like "Gandalf1, 1200bps...". I also agree with a recent remark about necessity of controlling the pulse/tone dialing mode. ~v~ Ed Howorka, erh@uvacs ~