[net.micro.cpm] mdm711.asm

smith%nrl-aic@sri-unix.UUCP (07/29/83)

From:  Russ Smith <smith@nrl-aic>

A recent note on the net re a bad mdm711.com somewhat underscores the
fact that it sure would be nice to be able to get mdm711.ASM. Is there
a GOOD reason why that isn't around? I can understand not wanting a
zillion new versions floating around but, as has been mentioned before,
some of us DO like to add our own stuff, or, as in my case, clean it up and
install other cpu (i.e. z80) code.

Russ (Smith@nrl-aic)

CSTROM@mit-mc@sri-unix.UUCP (07/30/83)

From:  Charlie Strom <CSTROM@mit-mc>

MDM711.ASM is indeed available all over the country on a number of
RCPM's. It mammoth size (about 80K squeezed) has discouraged wider
distribution. Irv Hoff is about to release MDM712 this weekend; the
update adds MCI-SPRINT-etc. capability to the smartmodem overlay and
has a few minor modifications, mostly specific to peculiar hardware
installations such as the Osborne. In addition, there are several new
overlays. You might want to wait for MDM712.ASM - I am sure that it
will be distributed along with the package.

-Charlie

W8SDZ@mit-mc@sri-unix.UUCP (07/30/83)

From:  Keith Petersen <W8SDZ@mit-mc>

MDM711.AQM (the squeezed version of MDM711.ASM) is available on MIT-MC
in AR100:W8SDZ;MDM711 AQM.  I did announce this to Info-Cpm some time
ago but guess you missed it.  Since the source code is not really
required anymore to get the program running, it was felt that it would
only confuse the issue to have it generally available.  Many people
don't read instructions before downloading files.  The instructions
say not to bother with the ASM file because all the options are in the
user overlays.  If you "clean it up" and "add Z80 code" (why?) you'll
be out of step with MDM712 when it becomes available.  If you have
some complaints/suggestions/modifications to submit, send them to
INFO-MODEM7@MIT-MC and I'll see that Irv Hoff gets them for inclusion
in the next version.  Alternatively, you can call him on the phone (he
isn't on the net) at (415) 948-2166, or contact him on CompuServe's
CP-MIG where he is VERY active and egar to answer questions.
--Keith

smith@nrl-aic@sri-unix.UUCP (07/30/83)

From:  Russ Smith <smith@nrl-aic>

Being out of step doesn't bother me too much, apparently I usually am...

I only recently started accessing the ARPANET hence missed your note on
AR100 (AR100 isn't in the last DIRLST for example). I'm looking
for something that works for my particular machine. Whether it's
transportable to someone else's (or even to any other machine I get
in the future) really doesn't matter at this point. I DO, however, get
real enjoyment from taking something good (such as mdm711) and 
modifying it in ways which make it a "better" program. For example,
I dislike most programs' user interfaces. Whether I'll like mdm711's
will be seen. If not, I'll change it to be screen oriented in a
style which meets whatever criteria that's pleasant to ME, perhaps
with pertinent status info displayed as well as graphic oriented
menus. This is something I'd do just for the Hollywood aspect of the
resulting process. Perhaps I'd take the output and send it to my
512x480 point plot display. Perhaps I'll just take the algorithms
behind the program, write them in MY idea of good C language, and
include all the bells and whistles which I think are nice.
Whatever...for these and other reasons I like to have my hands on
the source of programs I use. The fact that what I end up with
wouldn't be mdm711 is irrelevant. I WOULD end up with a program
which would allow my current system to access other systems using
the same protocol and whose basic algorithms had withstood the
tests of time. This is what's important to me; not that I have
the actual same program as others, but only that I can communicate
effectively with others and at the same time have a user interface
which appeals to ME, not necessarily only to the original designer.
MDM711 is the latest and greatest of the many MODEM programs, so
that's the source I feel would be best to start off from. Other
programs may use identical basic algorithms, but maybe mdm711
does something else better. Maybe I'll be COMPLETELY satisfied
with the way mdm711 is and not change it at all. That's for ME
to decide, though, not for others who believe they know what's
good for me.

Sorry about the rather rambling reply, it's just that the statement
about "confusing the issue" touched a raw nerve. It may be that
endusers of publicly distributed (and publicly touted) software
may want to make their own decision on whether to be confused.

In conclusion, to assume that someone who doesn't agree with
instructions on installing mdm711 hasn't read the same also is a
mistake. Indeed, I accessed and read just about everything I could
on the system in hopes that someone had slipped in a copy of
the source. I, of course, didn't access the "hidden" (to this
naive user, at least) AR100.

The contents of this note to the contrary, I truly appreciate the
rapid and helpful responses I received over the net re my original
plea. (I'd be willing to bet that more than a few other users of the
net also appreciate the responses...)

Needless to say, I'll be doing some happy hacking now that
I can get my greedy little hands on the source for mdm711.


Thanks to all (in particular to KP at MIT-MC),

Russ (Smith@nrl-aic)

W8SDZ%mit-mc@sri-unix.UUCP (07/31/83)

From:  Keith Petersen <W8SDZ@mit-mc>

Russ, my comments about being out of step were made with the
assumption that you, like others, might release an "updated version"
of MDM7xx.  As an RCPM Sysop, I am concerned with trying to coordinate
things so that two people don't do this at the same time.  That's why
I made the comment I did.  As it turns out, if you want to be truely
"up-to-date" you'll want to wait a day or two until I've had the
chance to upload MDM712, which was just released today.  It has enough
improvements and bug fixes that you'll want it instead of MDM711.
   If "C" language is what you want, don't re-invent the wheel.  We
have AR60:CPM;CMODEM 13C written in BDS-C and AR43:CPM;UMODEM 33C
written in Unix C.
   My point is that I am one of the coordinators for trying to keep
some order in the Public-Domain CP/M software world and if you intend
to share your efforts with others (I hope you do, your ideas sound
great), then please let me help guide you to what's available and
please keep me informed about what you're working on that might be
released to the public.  I'll see to it that word gets to the SYSOP
Clearinghouse RCPM system that we have set up specifically for this
purpose. 
   The AR100 does not show up in the CPM director because it's in the
W8SDZ directory and was intended as a temporary place for these
squeezed files (the whole LBR is there too as a binary file).
   Anytime you have questions about the CPM; directory or don't see
what you want there, please send a note to INFO-CPM-REQUEST@BRL rather
than the whole list, and Frank or I will get back to you (usually
within one day).
--Keith

goldfarb.ucf-cs@rand-relay@sri-unix.UUCP (08/07/83)

<<<FLAME ALERT -- LONG ONE>>>

Keith,
	I am once again incensed enough about the MODEM7 distributionitis
issue to revive the horse we beat to death a few months back.  My ire has
nothing to do with your correspondence with Russ; it is a reaction to your
announcement of the impending release of MDM712 a mere 29 days after MDM711
was released.  Since you have accepted the role of coordinator of RCP/M 
and public-domain software to a certain extent, I once again appeal to you
to help cause more control to be exercised over future releases of MODEM7.

	Here is a little history of the most recent releases along with 
the intervals between them:

              MDM712    7/30/83 
				 29 days
              MDM711    7/01/83 
				  9 days
              MDM710    6/22/83  
				 26 days
              MDM709    5/27/83  
				 12 days
              MDM708    5/15/83  
                                 34 days
	      MDM707    4/11/83
				  7 days
              MDM706    4/04/83

	My original appeal called for a moratorium on new features and a 
quarterly release schedule with intervening bug fixes in the form of diffs 
or DDT instructions.  I, too, maintain an RCP/M system here which, while not
as active or widely-known as yours, still has "customers" who are
knowledgeable and who want the lastest version of everything.  I don't 
blame them for that so I try to keep current.  But sometimes I will no
sooner have one version of MODEM7 on the system than another is released.
This gets old rapidly.  Not only do I have to procure and upload the basic
files such as MDM711.ASM (yes, Keith, the source -- we can cry about not
needing it until we're blue in the face, but people still want it),
MDM711.COM, etc., but also I must do the same with ALL the overlay files
which are changed in a miniscule fashion each time the package is upgraded.
There were 21 of these when I last looked. 

	Granted, the new features have been attractive and desirable.  But
in some cases there has been insufficient time for even a decent alpha
test.  The bugs are frequetly caught during beta testing which is done by the
end users (contrary to the notion of what a beta test should really be).
If Berkeley managed bsd Unix like MODEM7 is managed, I'd have to install
and debug a new operating sytem here every month or so.  (OK, perhaps this
is an unfair comparison -- maybe we should look at Rick Conn's excellent 
management of the ZCPR2 project as a better benchmark.)

	Let me restate the points I'd like to see addressed by this group:
            1)  A suitable time frame for major releases.  If we could 
                cause releases to be made no more frequently than quarterly
                it would allow time for sufficient alpha and beta testing.
		It would also ease the burden on RCP/M sysops.
            2)  Interim bug fixes and *minor* enhancements through the use
                of diffs and DDT patches.  If the program is well tested
                and features are well thought out, there shouldn't be too
                many of these.  
            3)  Generalization of the main program and the configuration
                modules such that each overlay file does not have to be
                regenerated for every new release of MODEM7.  As I
		mentioned above, there are now 21 overlays for various
		hardware configurations.  This number will surely grow
		as time goes on.
            4)  An end to the discussion about whether the source for 
		MODEM7 should be distributed.  I believe it has been shown
		that users do want it.

<<<FLAME OFF -- MY KEYBOARD RUNNETH OVER>>>

	Yes, I realize that we're dealing with public domain software that
represents the fruits of Irv Hoff's unpaid avocational efforts for which
he is seldom thanked.  Don't get me wrong, Irv has done a TREMENDOUS job
and he deserved to be thanked profusely for his labors.  I believe he has
finally refined MODEM7 to the point where it is robust enough and 
sufficiently generalized to make it an important part of every CP/M user's
software library.  Indeed, with the release of MDM711 I have put my money 
where my mouth is, junking MODEM216 and finally joining the rest of the world.
Also, I am not scorning your efforts on behalf of the CP/M community.  Your
tireless work is infrequently recognized yet you continue to spend much
time to keep the rest of us happy.  If it seems you are the target of this
flame, I apologize for that.  I merely want to see if we can jointly (all
of us) get a handle on the release situation and approach future releases
with a modicum of restraint and control.  I believe this will lighten the
load on Irv, yourself, and the rest of the MODEM7 distributors and users.

				Ben Goldfarb
				ARPA: goldfarb.ucf-cs@Rand-Relay
				uucp: {decvax,duke}!ucf-cs!goldfarb

P.S.
I'd appreciate it if someone could post this on CompuServe where Irv can
see it.