derek@uwvax.UUCP (03/26/87)
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
--
Abstract: Derek Zahn @ wisconsin
Usenet: ...!{allegra,heurikon,ihnp4,seismo,sfwin,ucbvax}!uwvax!derek
Arpa Internet: derek@rsch.wisc.edurjray@uokmax.UUCP (03/28/87)
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? Punter protocol was developed by Steve Punter, originally for use with his BBS program, 64BBS, currently in version 4.2. He is located here in Oklahoma, if my sources are correct. One good way to find out would be to contact the Greater Oklahoma Commodore Club. Provided that the mail system here is working right again (prayer, please) then contact me here at OU and I will try to get an address of the pres. or someone with power. Or, you can try their BBS at (405)/360-6130 and mail Chuck Pendley (SYSOP) and explain your purpose. It's a very active club, always willing to help, as am I... Randy rjray@uokmax.UUCP
rex@otto.UUCP (03/28/87)
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.
mark@unisec.UUCP (03/29/87)
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 |
rex@otto.UUCP (03/30/87)
Expires: Sender: Followup-To: Keywords: In article <451@unisec.USI.COM> mark@unisec.USI.COM (Mark Rinfret) writes: [A very lengthy rebuttal to my previously posted article concerning the punter transfer protocol] >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. > [removing my foot from my mouth...] I appreciate your reply to my obviouly flawed description of the Punter protocol. I was basing all my comments on a version of punter that appears to be long since outdated (it seem to be the only one in this area. everyone that uses punter around here is still running that version of the software and has never heard of there being updates. I guess that's one of the drawbacks to living in Las Vegas.). I would appreciate it if you could mail me locations of the newest versions of the software, and possibly source and Protocol descriptions, that you know of. Thanx, ** Rex Jolliff ** P.S. - It seems the first posting to the net an be the most painful... -- --------------------------------------------------------------------------- Rex Jolliff ------------------------------| The Sun Newspaper - | "Real Programmers don't | Nevada's Largest Daily Morning Newspaper | use BASIC or COBOL..." | Disclaimer: | | The opinions and comments in this article ------------------------------| are my own and in no way reflect the opinions | "Ack!" - bill the cat. | of my employers. -----------------------------
jose@utgpu.UUCP (03/31/87)
In article <489@uokmax.UUCP> rjray@uokmax.UUCP (Randy J Ray) writes: >In article <3372@rsch.WISC.EDU> derek@rsch.WISC.EDU (Derek Zahn) writes: [ Questions about what "Punter Protocol" is, where to get it, etc..., ommitted] > >Punter protocol was developed by Steve Punter, originally for use with You got this right, the but rest... hmm.... >his BBS program, 64BBS, currently in version 4.2. His bbs was originally written for PET's, not C64's. The current name of the C64 version is BBS64 and it is at version 4.2. > .... He is located here in >Oklahoma, if my sources are correct. One good way to find out would be Now this is wrong... I know for a fact that he does NOT live in Oklahoma because he lives some 20 minutes away from me! (And I live in Toronto, Ontario, Canada!) Please check your source's sources... [Rest of article deleted] You can contact Steve at (416)896-1446 from 10am. to 4pm. EST M to F by voice or you can contact his bbs at the same number from 6pm to 9am EST. (But be prepared to be dialling for a long time as his board is VERY busy all the time...) You can ask him about the protocol or the bbs itself but the protocol has been documented, by Steve, on a old issue of The Transactor, so it might be easier checking for this there... Again, Steve Punter lives in Mississauga, Ontario, Canada, but he is NOT on this net (but you can reach him on PunterNet, but that's another story... :-) > > Randy > rjray@uokmax.UUCP -- Jose Antonio Dias University of Toronto Computing Services ------------------------------------------------------------------------------- The above ascii characters are not, have not ever been, or will ever be, the opinion of anybody, being, or super-intelligent shade of the colour blue. They were just a fluke. They were put together by randomnly selecting phrases from Vogon poetry... ------------------------------------------------------------------------------- uucp: {decvax,ihnp4,utcsri,{allegra,linus}!utzoo}!utgpu!jose internet: jse@gpu.utcs.toronto.edu bitnet: JOSEatUTORONTO 300/1200 (416)535-5360 (As the crow flies... :-)
kinne@oswego.UUCP (04/02/87)
In article <304@otto.UUCP> rex@otto.UUCP (Rex Jolliff) writes: > > 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. > 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. Very true. This fact is the single worst thing I find with the protocol. > Second, the block size is hard set to 254 bytes. WRONG! Perhaps this was true in C1 protocol but it IS NOT AT ALL true for C2! You may certainly have variable block sizes, however your upper limit (to my knowledge) is set to 254 bytes. You may not go higher then that though you may transfer less. > Fourth, if you get a copy of the PD support package, don't bother trying to >disassemble it. The package is one big kludge. Can't say anything about the PD package as I've not seen it... > 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. Here is where I have a lot of problems with your posting, Rex. Though I am no expert (I've worked with a number of boards and terminals from a consulting or Sysop's viewpoint. I've tried some limited programming. My big problem (like everyone else) is time.) I find C2 Punters to be as standard as any other aspect of telecommunications for microcomputers. I have never had any problem in any transfer involving the Punter FTP (except for the inability to abort the transfer. This is a gripe I TOTALLY agree with you on!!). I find that every C64/C128 user I talk to who engages in telecommunications knows of and uses Punter. I have found it to be at least TWICE as fast as transfers involving X-Modem (perhaps I'm using X-modem incorrectly???). Finally, as for support, Steve has written a few tutorial articles on his protocol and runs his own BBS network (don't know if this qualifies for support but...). In conclusion, Rex is right in a way when he says Punter is not a standard; I've yet to see it implimented on anything but a C64/128. However, from the Users point of view, for those machines its the best thing going. I suspect that Rex has only seen a very old or very kludged source code for it which may be the problem... --- UUCP: seismo!rochester!rocksvax!oswego!kinne Doc Kinne CIS: 72457,2450 Instructional Computing Center Q-Link: Doc Kinne SUNY College at Oswego BBS: Gary's BBS:(315)598-8106 "The Doctor" Oswego NY 13126 (315)341-3055 "This is my age! I'm in the prime of my youth and I'll only be young once!" -Teddy Duchamp to Chris Chambers: Stand By Me DISCLAIMER: You WANT these opinions?????
mike2@lcuxa.UUCP (04/03/87)
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. ---------------------------------------------------------------------
a228moor@utcsscb.UUCP (04/05/87)
[Freems of the world unite!] I'm very new to this newsnet, so please excuse and/or correct any awful errors I may commit. First of all, what is C2? Is it anything like C1? This is the first that I've heard of it, which seems strange when I live in Toronto, close to the source of magic. I have a checksum/CRC XMODEM program for the c-64 which I might be able put up in this newsgroup, somehow. Oh well, back to Dungeon Construction Set... ---------------------------------------------------- Marc EM - I come in peace. Take me to your stove.
ben.pedersen@canremote.uucp (BEN PEDERSEN) (10/19/89)
Howdy Maxwell, In your message you asked, sP>I am looking for a C source to Punter protocal commonly used on sP>commodore machines. I'm interested in writing a transfer program for sP>the system I use andif someone had already written the program in C, sP>it would save me the work. Also, If you happen to know some of the sP>specifics about Punter, like a flow chart of how it handshakes, I sP>would appreciate mail on that also. I'm part- icularly interested in sP>writing a version that can handle multi-file transfers. If anyone has sP>any information on this in a language that is legible to me, C , sP>Basic, or Pascal, please send some mail. Thanks in advance... I have written a version of Steve Punter's C1 in C. I am not a professional programmer and so the structure of the code is probably not what it could be. It does work quite well though and Punter is using it in his PC-Punternet BBS program for MS-DOS machines. You can find both my source code and Steve's own written specification for C1 on his bulletin board PSI Wordpro, 416-896-1446, online from 6pm to 10am weekdays and 24hrs on weekends. If you have questions you can contact me here as I regularly monitor this conference. Ben Pedersen, Sysop C-Power BBS --Regards! --- * QDeLuxe 1.10 #2134