mat@emcard.UUCP (W Mat Waites) (03/11/89)
I'm looking for some documentation on the Punter protocol. I've got the 6502 source. I've seen the MS-DOS C source (it's pretty nasty). I'd like some real written documentation on how the protocol works. Figuring out the assembly source is not too appealing, but if that's what I've got to do..... Thanks for any help. Mat -- W Mat Waites | Bein' bad news is what we're all about; gatech!emcard!mat | We went to White Castle and we got throwed out. 8-5 ET: (404) 727-7197 | --B. Boys
jgreco@csd4.milw.wisc.edu (Joe Greco) (03/12/89)
In comp.sys.cbm article <6624@emcard.UUCP>, mat@emcard.UUCP (W Mat Waites) wrote: ]I'm looking for some documentation on the Punter protocol. ]I've got the 6502 source. I've seen the MS-DOS C source (it's pretty nasty). ] ]I'd like some real written documentation on how the protocol works. ]Figuring out the assembly source is not too appealing, but if that's ]what I've got to do..... I have a sugar coated overview of the protocol, describing the basics. Not at all technical. If you want to know how to use it, look at the BASIC program supplied with it. If you want to understand how it works, you're too advanced.... go get a real protocol. :-) -- jgreco@csd4.milw.wisc.edu Joe Greco at FidoNet 1:154/200 USnail: 9905 W Montana Ave PunterNet Node 30 or 31 West Allis, WI 53227-3329 "These aren't anybody's opinions." Voice: 414/321-6184 Data: 414/321-9287 (Happy Hacker's BBS)
mat@emcard.UUCP (W Mat Waites) (03/13/89)
In article <1531@csd4.milw.wisc.edu> jgreco@csd4.milw.wisc.edu (Joe Greco) writes: }In comp.sys.cbm article <6624@emcard.UUCP>, mat@emcard.UUCP (W Mat Waites) wrote: }]I'm looking for some documentation on the Punter protocol. } }I have a sugar coated overview of the protocol, describing the basics. }Not at all technical. If you want to know how to use it, look at the }BASIC program supplied with it. If you want to understand how it }works, you're too advanced.... go get a real protocol. :-) "You see, it's not for me.... it's.... it's.... it's for a ... friend, yeah, for a friend." Actually I'm tryng to implement punter in power C for a magazine article. So it's not like I really like punter, I'd just like to fully understand it for a couple of days. Mat -- W Mat Waites | Bein' bad news is what we're all about; gatech!emcard!mat | We went to White Castle and we got throwed out. 8-5 ET: (404) 727-7197 | --B. Boys
izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) (03/14/89)
> From: jgreco@csd4.milw.wisc.edu (Joe Greco) > Message-ID: <1531@csd4.milw.wisc.edu> > I have a sugar coated overview of the protocol, describing the basics. > Not at all technical. If you want to know how to use it, look at the > BASIC program supplied with it. If you want to understand how it > works, you're too advanced.... go get a real protocol. :-) No kidding. Steve's own description of the protocol he designed and wrote is flat out wrong in one or two places! And there are various stupid things done. First of all, each block header contains the size, in bytes, of the NEXT block so that the receiver can be certain (via the checksums) that it knows exactly how long the next block should be. OK, let's accomodate Steve on that one, even though it requires buffer space large enough to hold TWO blocks. Now, the sensible thing to do at the end of the file is simply indicate that the next block contains 0 bytes, right, and the acknowledgement of the last block also indicates understanding that the transfer is over. Well, Steve decided in stead that putting a 255 in the high byte of the block number would in stead be the signal. Quite aside of the fact that C1 is physically incapable of transferring files requiring more than 64,000 blocks, it means that something completely out of pattern must be checked for each & every time a block arrives. Since the sender & receiver are both sending GOO, BAD, ACK, or S/B at each other, Steve found that sometimes they would send simultaneously and the C64's RS-232 routines would garble the data, meaning that neither ever got the other's message. To solve this, the sender and receiver use different delay patterns: long-long-short and short-short-long. "Why not", ask I, "just have the sender use long delays and the receiver short ones?"... the answer, it seems, is that Steve is incapable of accepting such simple solutions. Steve is now working on C2 (his third protocol). It's a streaming protocol that requires that either the OS be able to seek to a random byte # in a file and read/write at the middle, or that the entire file be buffered/written to a temporary file, because bad blocks are re-sent after the whole file has been run through once. However, unlike his other two protocols, this one works only on machines for which people like Chuck Forsberg have already spent years perfecting protocols. I'm willing to be that C2 will not catch on, simply because it has REAL competition (not to mention that it is a late entry into the race). Geoff ( watmath!isishq!izot ) -- Geoffrey Welsh - via FidoNet node 1:221/162 UUCP: ...!watmath!isishq!171!izot Internet: izot@f171.n221.z1.FIDONET.ORG
jgreco@csd4.milw.wisc.edu (Joe Greco) (03/31/89)
In comp.sys.cbm article <1855.2423BBFD@isishq.FIDONET.ORG>, izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) wrote: ] ] > From: jgreco@csd4.milw.wisc.edu (Joe Greco) ] > Message-ID: <1531@csd4.milw.wisc.edu> ] ] > I have a sugar coated overview of the protocol, describing the basics. ] > Not at all technical. If you want to know how to use it, look at the ] > BASIC program supplied with it. If you want to understand how it ] > works, you're too advanced.... go get a real protocol. :-) ] ] No kidding. Steve's own description of the protocol he designed and wrote ]is flat out wrong in one or two places! Sometimes wrong, more often downright funny. It DOES give a basic understanding, however, and that is the only reason I keep it. (No others available...) ] And there are various stupid things done. First of all, each block header ]contains the size, in bytes, of the NEXT block so that the receiver can be ]certain (via the checksums) that it knows exactly how long the next block ]should be. OK, let's accomodate Steve on that one, even though it requires That makes sense, although I suspect that such a complex checksum would probably allow the block size for the current block to be encoded within the block.... which would allow for some "neat" things, such as intelligent block-sizing on the fly. Coding the NEXT block means that that block MUST go through at the current size, which may simply not happen on noisy lines. ]buffer space large enough to hold TWO blocks. Now, the sensible thing to do at RAM is cheap, they said that years ago. I have no argument against even 1K for buffer space. ]the end of the file is simply indicate that the next block contains 0 bytes, ]right, and the acknowledgement of the last block also indicates understanding Sensible, of course. ]that the transfer is over. Well, Steve decided in stead that putting a 255 in ]the high byte of the block number would in stead be the signal. Quite aside of I thought it was just highest bit (^15) set, but I could be wrong. Considering all the "pain" Steve put into making sure that blue-moon events would not cause problems elsewhere, that was dumb. I can make a 65000 block archive easily... (grins) ]the fact that C1 is physically incapable of transferring files requiring more ]than 64,000 blocks, it means that something completely out of pattern must be ]checked for each & every time a block arrives. ] ] Since the sender & receiver are both sending GOO, BAD, ACK, or S/B at each ]other, Steve found that sometimes they would send simultaneously and the C64's ]RS-232 routines would garble the data, meaning that neither ever got the ]other's message. To solve this, the sender and receiver use different delay ]patterns: long-long-short and short-short-long. "Why not", ask I, "just have ]the sender use long delays and the receiver short ones?"... the answer, it ]seems, is that Steve is incapable of accepting such simple solutions. Steve never accepted any of my ideas, solutions, suggestions, or ANYTHING regarding BBS64, and I know you have more experience with him than I. Is this news to you, Geoff? Come on. There might be some obscure merit to using "patterns," but I can't think of it.... but I'm sure he did, just so that he would be able to ignore your suggestion. (Steve at his finest). ;-) ] Steve is now working on C2 (his third protocol). It's a streaming protocol ]that requires that either the OS be able to seek to a random byte # in a file ]and read/write at the middle, or that the entire file be buffered/written to a ]temporary file, because bad blocks are re-sent after the whole file has been ]run through once. Steve is getting senile. ] However, unlike his other two protocols, this one works only on machines ]for which people like Chuck Forsberg have already spent years perfecting ]protocols. I'm willing to be that C2 will not catch on, simply because it has ]REAL competition (not to mention that it is a late entry into the race). Steve is unrealistic. I stated over a year ago that C2 will not catch on. Stated it. Also stated that BBS-PC (PC-PunterNet, or whatever he calls it now) will never catch on, and certainly never have more nodes than PunterNet on the 64.... there are too many GOOD BBS programs out for the PC that are so much less limiting, and that can work with FidoNet. How Steve expects to be able to compete with FN is beyond me. -- jgreco@csd4.milw.wisc.edu Joe Greco at FidoNet 1:154/200 USnail: 9905 W Montana Ave PunterNet Node 30 or 31 West Allis, WI 53227-3329 "These aren't anybody's opinions." Voice: 414/321-6184 Data: 414/321-9287 (Happy Hacker's BBS)
izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) (03/31/89)
> From: jgreco@csd4.milw.wisc.edu (Joe Greco) > Message-ID: <1759@csd4.milw.wisc.edu> > Sometimes wrong, more often downright funny. It DOES give a basic > understanding, however, and that is the only reason I keep it. (No > others available...) Agreed, hence my "C1.NOT" file, basically an appendix of corrections. > Steve is getting senile. No, he's always been extremely stubborn. When I met him (about the time he switched from Professional Software Inc. to Pro-Line), he was already in the mode of "I do it *my* way because I know better". The result was literally terrible word processor sales in face of more capable (and more public feedback sensitive) competition. > Also stated that BBS-PC (PC-PunterNet, or whatever he > calls it now) will never catch on, and certainly never have more nodes > than PunterNet on the 64.... there are too many GOOD BBS programs out > for the PC that are so much less limiting, and that can work with > FidoNet. How Steve expects to be able to compete with FN is beyond me. I have tried to tell him this (I gripe especially about PC-PunterNet's memory requiements, which prevent people from using it under DoubleDOS, which many SYSOPs regard with reverence), and am presently on his "I really don't want to talk to you" list. -- Geoffrey Welsh - via FidoNet node 1:221/162 UUCP: ...!watmath!isishq!171!izot Internet: izot@f171.n221.z1.FIDONET.ORG
jgreco@csd4.milw.wisc.edu (Joe Greco) (04/02/89)
In comp.sys.cbm article <1937.243411AF@isishq.FIDONET.ORG>, izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) wrote: ] ] > From: jgreco@csd4.milw.wisc.edu (Joe Greco) ] > Message-ID: <1759@csd4.milw.wisc.edu> ] ] > Sometimes wrong, more often downright funny. It DOES give a basic ] > understanding, however, and that is the only reason I keep it. (No ] > others available...) ] ] Agreed, hence my "C1.NOT" file, basically an appendix of corrections. Never seen it.... but as I said earlier, if someone is advanced enough to worry about it, it is time for them to move on to another protocol. ] > Steve is getting senile. ] ] No, he's always been extremely stubborn. When I met him (about the time he Oh, so he has always been senile. ]switched from Professional Software Inc. to Pro-Line), he was already in the ]mode of "I do it *my* way because I know better". The result was literally ]terrible word processor sales in face of more capable (and more public ]feedback sensitive) competition. Oh, that's right. WordPro was supposed to be a word processor.... I never did figure out any real use for it, besides using the manual to prop open my door (Please note that I have SEVERAL versions, including PET/CBM ones). Steve's obvious superiority to the rest of us .... well, let's see. So far, that has gained the computer world: (1) A BBS program for the 64 that is very picky about disk drives and interfaces, not to mention modems and interfaces. BBS64 is THE only program I have seen to date that will not work on my USR modems (but will work on a Hayes.) (2) An IBM release of his BBS program, which is presumably twice as picky ... I must be missing tons of stuff.... I at least have the decency to listen to user feedback and then act on it or proceed to explain why it is not practical.... and I have always made an attempt to make my software as UNIVERSAL as possible. (Works with RAMDOS64, no mods to the BBS, just a matter of locating RAMDOS.) Steve could learn. ] > Also stated that BBS-PC (PC-PunterNet, or whatever he ] > calls it now) will never catch on, and certainly never have more nodes ] > than PunterNet on the 64.... there are too many GOOD BBS programs out ] > for the PC that are so much less limiting, and that can work with ] > FidoNet. How Steve expects to be able to compete with FN is beyond me. ] I have tried to tell him this (I gripe especially about PC-PunterNet's ]memory requiements, which prevent people from using it under DoubleDOS, which ]many SYSOPs regard with reverence), and am presently on his "I really don't ]want to talk to you" list. As I've maintained.... Steve just isn't being realistic about PC-PN. That is one of the reasons he is on MY "I really don't want to talk to you, and I certainly could care less" list. However, I did have a merry old time giving him a rough time through network mail, making it worth the $70 or so I invested in a program I never ran. I cannot imagine how PC-PN can waste so much RAM, when a GOOD BBS (TBBS, etc) does 4 times as much in less memory. -- jgreco@csd4.milw.wisc.edu Joe Greco at FidoNet 1:154/200 USnail: 9905 W Montana Ave PunterNet Node 30 or 31 West Allis, WI 53227-3329 "These aren't anybody's opinions." Voice: 414/321-6184 Data: 414/321-9287 (Happy Hacker's BBS)
izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) (04/04/89)
> From: jgreco@csd4.milw.wisc.edu (Joe Greco) > Message-ID: <1789@csd4.milw.wisc.edu> > Steve's obvious superiority to the rest of us .... well, let's see. > So far, that has gained the computer world: (1) A BBS program for the > 64 that is very picky about disk drives and interfaces, not to mention > modems and interfaces. BBS64 is THE only program I have seen to date > that will not work on my USR modems (but will work on a Hayes.) (2) > An IBM release of his BBS program, which is presumably twice as picky > ... I must be missing tons of stuff.... That's funny; node 7 is running on a USR Sportster 2400 external, using an SSE Hardbox interface to a Corvus 20-meg hard drive via a G-Link IEEE interface. PC-PunterNet isn't as picky, but it is very memory-hungry. -- Geoffrey Welsh - via FidoNet node 1:221/162 UUCP: ...!watmath!isishq!171!izot Internet: izot@f171.n221.z1.FIDONET.ORG
jgreco@csd4.milw.wisc.edu (Joe Greco) (04/07/89)
In comp.sys.cbm article <1951.243806A7@isishq.FIDONET.ORG>, izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) wrote: > That's funny; node 7 is running on a USR Sportster 2400 external, using an >SSE Hardbox interface to a Corvus 20-meg hard drive via a G-Link IEEE >interface. PC-PunterNet isn't as picky, but it is very memory-hungry. That's funny; node 30 is NOT running on a USR Courier 2400 because BBS64 refuses to work reliably with it. If you'll recall, we went all around this subject on PN about half a year ago with Node 31 and the C2400 that Jim purchased. My problems are more serious than Jim's "occasional crash." However, due to Steve's attitude, the general lack of interest in PunterNet, the cost of adding Yet Another Phone Line (and monthly bills, too) and various other factors (BBS64's extreme maintenance demands ... especially), I see no reason to run the beast. HHBBS is chugging along quite nicely on a setup that is serving everyone just fine, and the interest in a second, network based BBS is nil. -- jgreco@csd4.milw.wisc.edu Joe Greco at FidoNet 1:154/200 USnail: 9905 W Montana Ave PunterNet Node 30 or 31 West Allis, WI 53227-3329 "These aren't anybody's opinions." Voice: 414/321-6184 Data: 414/321-9287 (Happy Hacker's BBS)