Platteter.Henr@PARC-MAXC.ARPA (11/29/83)
Your problem is with the 1200 baud. The software knows when the receive buffer is full but has no way to tell the machine that it is receiving the data from that it should not send any more data. There are two solutions. The first is to use 300 baud. This allows the receiving computer time to dump the buffer without loosing any data. The other solution is to use a modem program that allows you to insert delays before the sending of each line of data. I have used both successfully. I find that there is a lot less playing around if I just use 300 baud but if this option is not open to you you will have to use the other route. Later, DALE
FRIEDMAN@RU-BLUE.ARPA (12/05/83)
I tried to use Modem to transfer a file between 2 tops 20 machines. These machines are connected together via a 1200 baud terminal line. This is what I tried. Modem ctty# Modem t this brought me over to the other machine. next I typed Modem s foo ^E brought me back to the first machine. and now modem r foo to get the file. This worked fine for small files. If the file was longer than 16 blocks the receiving end aborted after 10 tries. I examined the incoming characters and everything seemed to be working fine. Does anyone know whats wrong? -Gadi <FRIEDMAN@RU-BLUE> -------
STANLEY@USC-ECLB.ARPA (08/28/85)
Received: from AMSAA by USC-ECLB; Wed 28 Aug 85 04:57:49-PDT
from brl-aos.arpa by AMSAA.ARPA id a009162; 28 Aug 85 7:28 EDT
from usc-isid.arpa by AOS.BRL.ARPA id a015896; 28 Aug 85 1:34 EDT
Date: 28 Aug 1985 01:32-EDT
From: ABN.ISCAMS@USC-ISID.ARPA
To: info-cpm@BRL.ARPA
Subject: TOPS-20 MODEM
Return-Path: <info-cpm-request@AMSAA>
Message-ID: <[USC-ISID.ARPA]28-Aug-85 01:32:36.ABN.ISCAMS>
Sender: ABN.ISCAMS@USC-ISID.ARPA
NetLandians,
Has anyone else experienced problems with the TOPS-20 file transfer program
MODEM when working through a TAC?
I've tested the latest from SIMTEL20 PD:<CPM.TOPS-20> (I think .315), and
same problem as the one on my host.
Symptoms: With two different versions of a micro MODEM using Christensen
Protocol (MODEM901 for the Compupro and MDM730 for my Decision I CP/M),
same error: Incorrect Record # (or was it Header #). Program never
begins to download. Watching and capturing the mainframe MODEM packet,
I see with a DUMP two ASCII 01 characters as a leader.
MODEM used to work for me quite a few months ago, but now no luck.
Uploads ("Sends") also fail -- MODEM first returns an ASCII 87H, and then
as I recall, CRs and sometimes a NAK. No packets move. Both Checksum
and CRC fail.
I experimented with toggling my TAC Trap (sending the TAC intercept character
twice), but to no avail.
Sure has me bugged! Would appreciate any help/suggestions.
Regards,
David Kirschbaum
Toad Hall
ABN.ISCAMS@USC-ISID
--------------------
David
I have had so much trouble with the TOPS-20 MODEM program for the
past two years that I finally gave uponit and use KERMIT
exclusively on the net. Nothing I or the ECLB folks did seemed
to help. Tried all of the TAC settings, too. KERMIT works, I
recommend it. (If using binary file transfer, set the TAC using
the command sequence @@d c a, @@b o s, @@b i s first.)
...DickWANCHO@SIMTEL20.ARPA (Frank J. Wancho) (08/28/85)
I already replied to Dave and the INFO-MODEMXX list, but forgot to include INFO-CPM. The problem is that beginning with the current version of TOPS-20 MODEM, you cannot simply take our .EXE file and expect it to run on your machine. In fact, I shouldn't have left it in that section. The reason is is that there are conditionals which depend on features in the TOPS-20 MONITR to handle network binary mode negotiations. Our MONITOR does it differently than it used to. What you need to do is grab the source file and compile it. If it still fails to work properly for you, let me know, and include the net address of your machine's wizard. --Frank
BillW@SU-SCORE.ARPA (William Chops Westfield) (08/29/85)
The MODEM.EXE from simtel20 is set up to use special monitor changes in their monitor that do things "right according to MRC" (Eg IAC doubling, special MTOPR for setting Telnet binary mode). This of course doesn't work on most tops20s - be sure to get the sources and set proper assembly conditionals, rather than just FTPing new binaries. There are basically three types of tops20 monitors: 1) Hacked monitor - doesn't do IAC doubling at all. This allows MODEM and KERMIT and so on to do their own telnet negotiations, and tehrefore work, as long as they also remember to double their own IACs too. Unwary programs may have characters mysteriously disappear when they try to output a 0FFh without this doubling. I think Vanilla DEC software looks like this - it is the most likely version for your arpanet tops20 system to have. 2) Broken monitor - does IAC doubling (or tries to), but doesn't have MTOPR for setting binary mode on tcp telnet connections. In order for this to work with modem at all, you have to do @B I S, @B O S, on your TAC by hand, which you can not then turn off. This was a result of trying to fix type 1 monitors, without allowing for the fact that user software was counting on the "bugs". There is also a REALLY BROKEN monitor that refuses to enter binary telnet mode at all, but this version has hopefully dissappeared. 3) Panda (MRC) monitor. Does IAC doubling, but also provides a special call for negotiating network binary mode. This version is probably the closest to "correct", but doesn't have very wide distribution (the edits are "Panda Proprietary"), and suffers somewhat in terms of efficiency. SIMTEL runs this version. BillW