Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!cit-vax!usc-oberon!sdcrdcf!otto!rex From: rex@otto.UUCP Newsgroups: comp.sys.cbm Subject: Re: Punter protocol Message-ID: <304@otto.UUCP> Date: Sat, 28-Mar-87 06:50:21 EST Article-I.D.: otto.304 Posted: Sat Mar 28 06:50:21 1987 Date-Received: Sun, 29-Mar-87 09:47:54 EST References: <3372@rsch.WISC.EDU> Reply-To: rex@otto.UUCP (Rex Jolliff) Distribution: comp Organization: Las Vegas Sun - Nevada's Largest Daily Morning Newspaper Lines: 77 Summary: Expires: Sender: Followup-To: Keywords: In article <3372@rsch.WISC.EDU> derek@rsch.WISC.EDU (Derek Zahn) writes: >Hi. Does anyone outh there know anything about a data transfer method >used by C64's called 'Punter'? Specifically, I am working on a BBS- >type system and would like to support Punter transfers. Is there a >protocol description somewhere? > >Any information would be greatly appreciated. > >derek >Usenet: ...!{allegra,heurikon,ihnp4,seismo,sfwin,ucbvax}!uwvax!derek Are you sure you want to support Punter transfers? I have worked on and/or built from scratch quite a few different Bulliten Board Systems, and out of all them, two of them supported the Punter protocol. Both of the systems that supported punter were not written by me, and they used a public domain Punter transfer support package written in machine language. There are a lot of problems with this software package. First, there is no smooth way to abort from a transfer manually. If the commodore key is struck during a transfer, it aborts from one side, but it does not inform the other side that the transfer has been aborted. There seems to be a transfer abort code (see flame about block codes in latter part of article) in the support package (see flame about coding style), but it does not work. Second, the block size is hard set to 254 bytes. The reason it is 254 bytes is simple, that is the size of a cbm disk block. Since the system sends exactly one disk block to the disk controller, the disk controller can save the block to disk while the system retrieves the next block from the modem (aren't multiple processors wonderful!). The problem here is that if you have an incredibly clean line you can save lots of transfer time by transferring bigger blocks. Or, if you an incredibly dirty line, you can save time by transferring smaller blocks. It should be obvious why this is true. If you're using the Punter protocol, you're hopelessly stuck with one block size. Third, most transfer protocols send data by taking sections of the data, usually called blocks or packets, putting start, stop, and checksum bytes together with the data and sending it over the transfer medium. The other side then receives it, strips off the start, stop, and checksum bytes, and does an error check using the checksum byte. With small computers, like the c-64, there is no need for more than about five or six control codes. All the control information can easily fit in one byte with room left over for other info if needed. The Punter protocol uses 3 byte sequences for the control codes (example: 'ACK', 'NAK', 'GOO', 'BAD', and 'XXX' the supposed abort). The unnecessarily long control codes waste a lot of time and increase the probability of error. Fourth, if you get a copy of the PD support package, don't bother trying to disassemble it. The package is one big kludge. There is a source code file floating around PD land (I think I saw it on COMPUSERVE), but it is hard to find it is about as easy to decipher as the binary file that it produces. Fifth, probably the biggest bummer about the Punter file transfer protocol is that it is nowhere close to being a standard. Nobody uses it except a certain number of cbm users that have the delusion that this protocol is better than x-modem, or cbm users that don't know about other protocols. It is too bad that Steve Punter (the inventor of the Punter protocol, of course) didn't think about these things when he wrote this protocol. He doesn't seem to support his protocol at all either, but I could be wrong. It would probably be a lot easier and a lot more productive to dig up a PD terminal program that supports x-modem and keep a version of Punter handy, so you can transfer the x-modem terminal prog. to the people that only have the punter terminal prog. I hope I was helpful, and if you still need info on the punter protocol, mail me and I will put together a description for you. I don't mean to offend Steve Punter or any of his software, but I do think it has a lot of bugs and he should at least give some advice on how to rectify them to the people who use his transfer protocol. ** Rex Jolliff ** --------------------------------------------------------------------------- Rex Jolliff The Sun Newspaper - Nevada's Largest Daily Morning Newspaper Disclaimer: The opinions and comments in this article are my own and in no way reflect the opinions of my employers. -- --------------------------------------------------------------------------- Rex Jolliff The Sun Newspaper - Nevada's Largest Daily Morning Newspaper Disclaimer: The opinions and comments in this article are my own and in no way reflect the opinions of my employers.