w8sdz%brl@sri-unix.UUCP (11/27/83)
From: Keith Petersen <w8sdz@brl> The problem with your TOPS-20 can be EASILY fixed. It involves a simple patch to the system monitor to correct a bug in the way it negotiates with your TAC. WANCHO@SIMTEL20 or BILLW@SRI-KL have full particulars. It should not be necessary for you to ASCII capture ANYTHING. --Keith
G.WBC3@COLUMBIA-20.ARPA (11/30/83)
From: Bill Catchings <G.WBC3@COLUMBIA-20.ARPA> In answer to LHILL's question, there is a hexify program (by that name no less) that exists for Tops-20. While I agree Kermit and other programs should be able to cope with things like a TAC, there are times when it is nice to have a work around. The program was written by Bruce Tanner and can be found in the directory PS:<KERMIT> at Columbia-20 on the ARPAnet. I've never used it myself, but the 8080 and Z80 crosscompiler for Tops-20 by Bruce works very well. I assume the hexify program works as well. -Bill Catchings -------
ABN.ISCAMS%usc-isid@sri-unix.UUCP (12/01/83)
Confirm Bill Catching's comments on sometimes needing a hexify program. Working through a TAC still gives me problems with binary files since, all rumors and facts to the contrary, my g------ed TAC will NOT reset itself once I disconnect, and I lock up the bloody unmentionable port until my TAC owners go and kick the front panel or something. Soooo .. I HEXIFY com files regularly. Incidentally, my regular assemblers don' like HEXIFY-produced hex files so very much, but if I load them into DDT and then save them -- perfect! Don't let the visual appearance of a HEXIFY-produced file scare you, either. Sure, each line of hex is almost as wide as an 80-col screen (much different from HEX files produced by regular CP/M assemblers), but not to worry -- DDT handles them just fine (guess it's a function of the 32-bit word (well, kind of a 32-bit word) the DEC uses -- don't really care; it works!). Regards, David Kirschbaum Toad Hall