Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!princeton!allegra!ulysses!gamma!pyuxww!lcuxc!lcuxb!lcuxa!mike2 From: mike2@lcuxa.UUCP Newsgroups: comp.sys.cbm Subject: Re: Punter protocol Message-ID: <136@lcuxa.UUCP> Date: Fri, 3-Apr-87 15:09:32 EST Article-I.D.: lcuxa.136 Posted: Fri Apr 3 15:09:32 1987 Date-Received: Sun, 5-Apr-87 08:00:59 EST References: <3372@rsch.WISC.EDU> <304@otto.UUCP>, <346@oswego.UUCP> Organization: Bell Communications Research, Piscataway, NJ Lines: 118 I almost (but not quite) hesitate to put my 2 cents into this discussion, but I can't resist .... It's been quite some time since I went into Steve Punter's protocol deeply, but I did do so several years ago when he released the C2. Also, I abandoned the C64 to the kids over a year ago, and lost interest in developing applications for it. But, my memory of when I still had that interest is: 1. It is true that Punter did not include a graceful way of aborting a transfer, but it is relatively easy to "gimmick" one outside the ml protocol itself. Look at the basic program (in the original unadorned and unintegrated version of term.c2/terminal.c2) for the code that starts and ends the transfer and you will see how to send characters (i.e., with a print# command). Remember that the "S/B" (8 bits, no parity) handshake will cause the other end to retransmit. Know also that the other end's ml program will abort its controlling bbs program when it has received too many retransmission requests (if I remember right, it is 10 in a row). Know also that when a Punter transfer is aborted through the C= key, it returns from the ml code to the basic program. Therefore, to gracefully abort, when there is a return to the basic program simply send the appropriate number of "S/B"s to the other end, and cause it also to abort. Alternatively, simply wait. Punter has a timeout built into the protocol, and most BBS programs will accept a timeout abort from the ml program that they are using to implement the protocol. The foregoing is to abort the transmitter from the receiving end. To abort from the transmitting end, simply send "EOF" (or is it "EOT") as the 3 character handshake code (not the ASCII control d!). 2. If you want to do the foregoing within the ml program (and this may be necessary if you are at 1200 baud, where interpreter basic will not adequately keep up!), as I recall you have to play with the ml equivalent of a sys 49173 to avoid some "deadly embraces" that can occur using Punter's substitute for Commodore's character read kernel call. The reason Steve wrote his own is that the kernel call will not read a $00 (or 00H to the DOS world) byte; it thinks the zero is an call to an empty port. The sys 49173 (or nearby) call is a reset to his own read routine, and I vaguely remember that it must be called before sending as well. 3. XMODEM for the C64 has a dismal history, which may have led many to conclude that it is slower than Punter's routine. This "just ain't so." Karl Schmitt originally wrote an XMODEM implementation in interpretor basic that had several problems. It was too slow; it did not completely implement Christensen's algorithm; and it could create timing problems with the remote end. Some of us in the Washington, D.C. area rewrote the code in basic, and included an on-the-fly ASCII/Petascii conversion capability (which usually is needed in transfers to other computers). We then compiled it so that it would work full speed. To avoid the "how do you read a zero byte problem" of #2 above, we used Punter's approach in a small ml program that was engrafted on the compiled code. This led rapidly to the observation that the two programs, Punter and XMODEM, should be integrated and share the I/O routines in Punter's code; that was the combination of compiled basic and ml program that floated around in DC about 2 years ago. The other change we made -- which I heartily recommend in all Punter implementations -- was to substitute an F1 for the CLR/HOME call that Punter uses to get to the menu. CLR/HOME is a control s in cbm-land; it also is XOFF in many systems which you might want to stop from scrolling. You can't send it if it is used the way Punter intended. Finally, my own customization was to make the INS (that is, capital DEL) an ascii 255 (RUBOUT); it's nice to have such a key when talking to a *NIX system! The net result was an XMODEM program that worked, but because the compiled basic was slower than ml it worked at about 75% of the throughput rate of a Punter transfer. 4. Thereafter, Tony Snyder, then operating the absolutely **best** C64 bbs around (20 mb hard disk in 1983 for the C64!) took the basic code and rewrote it in assembler. At the time he lost interest in it, it worked blazingly fast -- somewhat faster than Punter -- in XMODEM, but had a slight problem. Specifically, it would turn on the drive motor and leave it on until the transfer ended. He did not implement buffering to minimize disk calls, and he didn't want to wait for the motor to come to speed each time there was a disk write/read. A continually turning drive was a bit unnerving. 5. The last I heard, about 1-1/2 to 2 years ago, was that someone in Texas had released in FREEWARE an even faster ml XMODEM program than Snyder's. Unfortunately, it did not have the ASCII/Petascii conversion capability, but it actually ran faster than Punter. My memory is that at 300 baud you run about 6 254 byte Punter blocks/minute. The Texas version of XMODEM ran about 13-14 128 byte XMODEM blocks/minute, which is slightly faster. 6. Finally, all of the XMODEM implementations that I had seen were original Christensen checksum varieties. I am not aware of any CRC implementations for the C64. Oh yes, when I disassembled term.c2 around 1985, I remember finding that there were two check bytes sent in each packet. The first, as the earlier posting said, was a simple one-byte checksum (tossing carries like XMODEM). But the second, as I remember it, was not quite as described by Punter. As I recall, the algorith was to take each data byte and XOR it against a register containing the results of XORs with previous bytes. Such an algorithm suffers from many of the same transposition error potentials of a checksum, but the saving grace is that in most circumstances where a transposition would pass the checksum it would fail the XOR, and vice versa. I do not remember seeing the type of LSR that typically implements a true CRC, and in any event if one is to take the overhead of a two-byte check it probably would be better to implement a 2 byte CRC-16 than what Punter did. As a user, however, I can confirm that in some 55 disks packed with files received over the modem, I never had a single error using Punter's protocol. Either I was fortunate enough to have very good telephone lines, or the protocol really works. Cheers. Mike Slomin _____________________________________________________________________ The foregoing were my views, and my views alone. Any resemblance between these views and common sense is purely coincidental. ---------------------------------------------------------------------