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 ------- -------