BILLW@SRI-KL.ARPA (11/28/83)
From: William "Chops" Westfield <BILLW@SRI-KL.ARPA>
The problem is that the current implementation of TOPS20 is not
"properly written". It is broken. It isnt even clear that it
will work if you give your TAC an @B I S command sequence....
Here is the a description and solution to the BINARY MODE
problem on TOPS20.
---------------
Date: Mon 1 Aug 83 14:17:59-PDT
From: BILLW@SRI-KL.ARPA
Subject: [Frank J. Wancho <FJW @ MIT-MC>: [pditmars: Binary]]
To: info-modemxx@MIT-MC.ARPA, tops20@SU-SCORE.ARPA
As some of you may know, there are a series of programs for
downloading microcomputers from Tops-20 systems. Recently, a new
version of TAC code was installed, and these programs stopped working
when used through a TAC. After much searching, this was finally
tracked down to a bug in Tops-20 (or a mis-feature) that was agravated
by the new TAC code. A patch has been developed (and is enclosed).
This patch has been tested at SRI and at SIMTEL20, and should be
installed if you have any users who use the MODEM program to download
micros over the ARPANet.
Bill Westfield
-------------
Date: 24 June 1983 12:29 EDT
From: Frank J. Wancho <FJW @ MIT-MC>
Subject: [pditmars: Binary]
To: BillW @ SRI-KL
Bill,
Peter patched my TAC port so that he could capture the TCP headers in
a dump. I ran MMODEM on MC first, to demonstrate a working version.
Then I ran your MODEM (still 125) on XX. Here's is his results so
far. I thought you'd be interested... --Frank
--------------------
Date: 24 Jun 1983 11:14:32 EDT (Friday)
From: Pieter Ditmars <pditmars at BBN-UNIX>
To: fjw
cc: taccers at BBN-UNIX, pditmars at BBN-UNIX
Re: Binary
Frank,
Results of the dump proved inconclusive, though something funny
seems to be going on. Can't see the first IAC from xx but it should
be a "will binary" cause the TAC responds do binary. Then xx says
wont binary and the tac gives don't binary. Finally xx sends do
binary to which the TAC does not reply. Looks like we got a bug here
new tests in progress will msg you when isolated. Pete
Date: 27 Jul 1983 18:26-PDT
From: William "Chops" Westfield <BillW @ SRI-KL>
To: Wancho@SIMTEL20
Cc: billw@SRI-KL
Here is a bug fix that might help fix the downloading through TAC
problem. First, the suspected reason it doesnt work:
The 20 sends "WILL BINARY". The TAC receives this and,
if binary is not already set, responds with a positive
"DO BINARY" (this explains why it will work if you put
the TAC in binary mode BEFORE you connect to the host).
The 20 monitor receives the "DO BINARY", and is currently
set to refuse this option (I consider this a bug, and plan
to complain to DEC - It will help if other Net heavyweights
complain also), so it sends "WONT BINARY",and the TAC
responds "DONT BINARY", leaving things in NON-binary mode.
The reason this probably worked in older versions of the
TAC code is that the TAC probably ignored the second "DONT
BINARY" and just transmitted all 8 bits from the host anyway.
Thus this is really a bug in TOPS-20, and not in the new TAC
code.
Now, here is the fix:
In module TTNTDV, at location NVTDOD, change
NVTDOD: IFIW!R
to
NVTDOD: IFIW!RSKP
(This can also be done to the binaries, of course, and
its relatively safe to do to a running monitor:
@MDDT
call SWPMWE$x ;write enable swappable monitor
NVTDOD/ SETZ RSKP ;make the change
call SWPMWP$x ; write protect monitor again
^Z ;exit MDDT )
This will cause TOPS20 to reply "WILL BINARY" whenever
it receives "DO BINARY", which chould not cause any
problems. The PROPER thing to do is to reply positively
only if the program on the other end is reading from
the terminal in binary mode, and refuse otherwise. Putting
the terminal in binary mode should take care of everything.
Unfortunately, the relevant code (NVTMOD) has been commented
out of the current monitor.
Please let me know if this works...
Bill Westfield
-------
-------