Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!necntc!rayssd!unisec!mark From: mark@unisec.UUCP Newsgroups: comp.sys.cbm Subject: Re: Punter protocol Message-ID: <451@unisec.USI.COM> Date: Sun, 29-Mar-87 08:25:58 EST Article-I.D.: unisec.451 Posted: Sun Mar 29 08:25:58 1987 Date-Received: Sun, 29-Mar-87 23:49:28 EST References: <3372@rsch.WISC.EDU> <304@otto.UUCP> Distribution: comp Organization: UniSecure Systems, Inc. Newport, R.I. Lines: 131 Summary: Punter misinformation! I couldn't let this slip by. Rex, I believe you are terribly misinformed on this subject and shouldn't have done others the disservice of misleading them with your prejudices. In article <304@otto.UUCP>, rex@otto.UUCP (Rex Jolliff) writes: - 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'? .... - - 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 ^^^^^^^^^^^^^^^^^^^^^^ What software package? The Punter BBS is one of the best designed BBS applications (from the user perspective) that I've seen on any machine! - 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 ^^^^^^^^^^^^^^^^^^^^^^^ Here, you're talking about the terminal emulation program used during the transfer. The Punter BBS, used with the proper terminal software, will abort gracefully (I've done so on occaision when I've run out of disk on a download). - 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 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Absolute hogwash! Sounds like your terminal program didn't provide the ability to tell the host what block size to you. That's the terminal program implementor's fault, not Punter's. - 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. ^^^ -- see above -- ^^^^^^^^^^^^^^^^ - 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 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Hmmm....that's an amazing concept! How big ARE your bytes, anyway? - 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. ^^^^^^^^^^^^^^^^^^^^ It is true that Punter protocol has more overhead than, say, XMODEM, but in practice I've only noticed about a 7-10% time differential. Your other remark about increasing probability of error is absurd. Punter protocol can recover from just about anything short of total line failure. - 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. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I guess it depends upon your experience level. I had no trouble converting the PAL assembly language file to CBM format, then to my own assembler which ran under C-Power. I was able to make several changes that allowed me to embed the support package in a C language terminal emulator as well as an all-assembly version. - 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 ^^^^^^^^^^^^^^ The Punter BBS network is probably the largest group of bulletin board systems in the U.S. and Canada. Never heard of Punter-Net, eh? - number of cbm users that have the delusion that this protocol is better than ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I would definitely rate it better than XMODEM, more efficient than Kermit. Punter protocol assures me an EXACT copy of the file being transferred, without any padding garbage at the end of a bogus 128 byte block limitation. - 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. ^^^^^^^^^^^^^^^^^^^^ This is the first correct statement you've made, so far. - 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. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Please, spare us! Punter has written his own document which describes the protocol very well. It's available on his Ontario BBS (Node #1). I have a copy and may be able to post it later this week. - - I don't mean to offend Steve Punter or any of his software, but I do think ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ You probably did - he has an ego as big as all outdoors. I don't think you can offend software, however :-) . - it has a lot of bugs and he should at least give some advice on how to rectify ^^^^^^^^^^^^^^^^^^^^ This kind of statement is quite irresponsible and very inaccurate. - 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 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Thank goodness! - the opinions of my employers. - -- -- | Mark R. Rinfret, SofTech, Inc. mark@unisec.usi.com | | Guest of UniSecure Systems, Inc., Newport, RI | | UUCP: {gatech|mirror|cbosgd|uiucdcs|ihnp4}!rayssd!unisec!mark | | work: (401)-849-4174 home: (401)-846-7639 |