joseph@valnet.UUCP (Joseph Hillenburg) (08/18/90)
These are the features I would like to seen in JR-Comm 1.10. 1) 2.0 compatibility - Reason: I don't want to pick up a new copy of JR-Comm, tehen have it break when I get OS 2.0. 2) ARexx - Reason: Why not? 3) Scripts -Although, if ARexx is properly implemented, this won't be neccesary. 4) XPR support. 5) IBM Color and Mono wrapped up into one. 6) The following XPR protocols: XPRxmodem, XPRymodem, XPRzmodem, XPRjmodem, XPRkermit, XPRascii, XPRSealink(?), and XPRsadie. 7) Less "undesirable features". (bugs) Circumstances prevent me from mailing John (Jack?) Radigan a registration form. J.P. Radigan, if you are reading this, please send me a form. I would gladly register if you did. (My PaintJet is in the Shop). ************************************************************************** * -Joseph Hillenburg (Sultan of Asm) * "Those are't bugs!" * * Addresses: * "Just undesirable features!"-Me * * INET: joseph@valnet.uucp ************************************* * UUCP: ...!iuvax!valnet!joseph * Call CompSci BBS * 1-812-873-440 * * MAIL: 1709 West Gray * 3/12/24 * 10pm-6am EST * * MAIL: Bloomington, Indiana ************************************* * MAIL: 47401 United States * Mail replies requested * **************************************************************************
jprad@faatcrl.UUCP (Jack Radigan) (08/19/90)
joseph@valnet.UUCP (Joseph Hillenburg) writes: >1) 2.0 compatibility - Reason: I don't want to pick up a new copy of >JR-Comm, tehen have it break when I get OS 2.0. Will have it with 1.01. >2) ARexx - Reason: Why not? >3) Scripts -Although, if ARexx is properly implemented, this won't be >neccesary. Probably for 1.2. >4) XPR support. Definately for 1.1. >5) IBM Color and Mono wrapped up into one. Are you refering to 16 colors w/blinking attribute? If so, maybe in the future, but not now. If not, what are you refering to? >6) The following XPR protocols: XPRxmodem, XPRymodem, XPRzmodem, >XPRjmodem, XPRkermit, XPRascii, XPRSealink(?), and XPRsadie. I'll put the hooks in there for XPR, but I won't be writing the XPR modules except for the CIS B+ one since I'll be removing that protocol from the program. As for ZMODEM, an XPR module could never acheive the throughput that the internal code gets, so that will remain internal. >7) Less "undesirable features". (bugs) This goes without saying... >Circumstances prevent me from mailing John (Jack?) Radigan a registration >form. J.P. Radigan, if you are reading this, please send me a form. I >would gladly register if you did. (My PaintJet is in the Shop). Ok, will do. -jack-
arc@desire.wright.edu (08/19/90)
In article <72@faatcrl.UUCP>, jprad@faatcrl.UUCP (Jack Radigan) writes: > joseph@valnet.UUCP (Joseph Hillenburg) writes: > >>1) 2.0 compatibility - Reason: I don't want to pick up a new copy of >>JR-Comm, tehen have it break when I get OS 2.0. > > Will have it with 1.01. > >>2) ARexx - Reason: Why not? >>3) Scripts -Although, if ARexx is properly implemented, this won't be >>neccesary. > > Probably for 1.2. > >>4) XPR support. > > Definately for 1.1. > >>5) IBM Color and Mono wrapped up into one. > > Are you refering to 16 colors w/blinking attribute? If so, maybe in the > future, but not now. If not, what are you refering to? > >>6) The following XPR protocols: XPRxmodem, XPRymodem, XPRzmodem, >>XPRjmodem, XPRkermit, XPRascii, XPRSealink(?), and XPRsadie. > > I'll put the hooks in there for XPR, but I won't be writing the XPR modules > except for the CIS B+ one since I'll be removing that protocol from the > program. As for ZMODEM, an XPR module could never acheive the throughput > that the internal code gets, so that will remain internal. > >>7) Less "undesirable features". (bugs) > > This goes without saying... > >>Circumstances prevent me from mailing John (Jack?) Radigan a registration >>form. J.P. Radigan, if you are reading this, please send me a form. I >>would gladly register if you did. (My PaintJet is in the Shop). > > Ok, will do. > > -jack- Jack, I have used your JRComm for a while now, and find it very nice. About the internal ZModem, I don't find it that efficient... I have used NComm 1.9 with it's external ZModem, and it takes MUCH less CPU time (I used XOper, plus by doing some mtasking, etc.) for all xfering. I run your term at a 0 priority, just as I do NComm 1.9 (NComm 1.9 is buggier than JRComm 1.0), but the Zmodem library does an AWSOME job. I will be uploading with JRComm 1.0 at a 0 priority (on its own screen) and then when I go to resize a window on my workbench screen (interlaced) your term pause the transmit for a split second... This really bothered me that you'd say that an external ZModem wouldn't achieve the thoughput that your internal does... It's a fine program, and I would VERY much like to send in my donation and registration... I don't know, maybe I'm asking too much? Think so? ------------------------------------------------------------------------ = /// | Jim Perry | Arc@Desire.Wright.edu = = /// Amiga! | ^Communications Consultant| -or- = = \XX/ The One | Arc Electronics, Inc. | Arc@WSU.BITNET = = ____& Only... | Wright State University |"Ouch! Quit-it." - Bart= = | Dayton, Ohio | Frank Sinatra Rules = ========================================================================
lshaw@walt.cc.utexas.edu (logan shaw) (08/19/90)
In article <ias3N10w162w@valnet.UUCP> joseph@valnet.UUCP (Joseph Hillenburg) writes: >These are the features I would like to seen in JR-Comm 1.10. [several other good ideas deleted, including ARexx port] >6) The following XPR protocols: XPRxmodem, XPRymodem, XPRzmodem, >XPRjmodem, XPRkermit, XPRascii, XPRSealink(?), and XPRsadie. Or even plain old kermit only would be nice. >7) Less "undesirable features". (bugs) Yeah, that's always good. And now for my own: 8) PROPER vt100 emulation. (Try using emacs, you can't set a mark) >************************************************************************** >* -Joseph Hillenburg (Sultan of Asm) * "Those are't bugs!" * >* Addresses: * "Just undesirable features!"-Me * >* INET: joseph@valnet.uucp ************************************* >* UUCP: ...!iuvax!valnet!joseph * Call CompSci BBS * 1-812-873-440 * >* MAIL: 1709 West Gray * 3/12/24 * 10pm-6am EST * >* MAIL: Bloomington, Indiana ************************************* >* MAIL: 47401 United States * Mail replies requested * >************************************************************************** ============================================================================ "The beauty queen, clevely clad, Logan Shaw admires herself in a cigarette ad. lshaw@ccwf.cc.utexas.edu Will she admit that all was in vain ======================== when the face in her mirror cracks like a windowpane?" -Elim Hall, _Things_Break_
joseph@valnet (Joseph Hillenburg) (08/19/90)
arc@desire.wright.edu writes: > In article <72@faatcrl.UUCP>, jprad@faatcrl.UUCP (Jack Radigan) writes: > > joseph@valnet.UUCP (Joseph Hillenburg) writes: > > > >>1) 2.0 compatibility - Reason: I don't want to pick up a new copy of > >>JR-Comm, tehen have it break when I get OS 2.0. > > > > Will have it with 1.01. > > > >>2) ARexx - Reason: Why not? > >>3) Scripts -Although, if ARexx is properly implemented, this won't be > >>neccesary. > > > > Probably for 1.2. > > > >>4) XPR support. > > > > Definately for 1.1. > > > >>5) IBM Color and Mono wrapped up into one. > > > > Are you refering to 16 colors w/blinking attribute? If so, maybe in the > > future, but not now. If not, what are you refering to? > > > >>6) The following XPR protocols: XPRxmodem, XPRymodem, XPRzmodem, > >>XPRjmodem, XPRkermit, XPRascii, XPRSealink(?), and XPRsadie. > > > > I'll put the hooks in there for XPR, but I won't be writing the XPR modules > > except for the CIS B+ one since I'll be removing that protocol from the > > program. As for ZMODEM, an XPR module could never acheive the throughput > > that the internal code gets, so that will remain internal. > > > >>7) Less "undesirable features". (bugs) > > > > This goes without saying... > > > >>Circumstances prevent me from mailing John (Jack?) Radigan a registration > >>form. J.P. Radigan, if you are reading this, please send me a form. I > >>would gladly register if you did. (My PaintJet is in the Shop). > > > > Ok, will do. > > > -jack- > > Jack, I have used your JRComm for a while now, and find it very nice. Abo > the internal ZModem, I don't find it that efficient... I have used NComm 1.9 > with it's external ZModem, and it takes MUCH less CPU time (I used XOper, plu > by doing some mtasking, etc.) for all xfering. I run your term at a 0 > priority, just as I do NComm 1.9 (NComm 1.9 is buggier than JRComm 1.0), but > the Zmodem library does an AWSOME job. I will be uploading with JRComm 1.0 a > a 0 priority (on its own screen) and then when I go to resize a window on my > workbench screen (interlaced) your term pause the transmit for a split > second... This really bothered me that you'd say that an external ZModem > wouldn't achieve the thoughput that your internal does... It's a fine progra > and I would VERY much like to send in my donation and registration... I don' > know, maybe I'm asking too much? Think so? > > > ------------------------------------------------------------------------ > = /// | Jim Perry | Arc@Desire.Wright.edu = > = /// Amiga! | ^Communications Consultant| -or- = > = \XX/ The One | Arc Electronics, Inc. | Arc@WSU.BITNET = > = ____& Only... | Wright State University |"Ouch! Quit-it." - Bart= > = | Dayton, Ohio | Frank Sinatra Rules = > ======================================================================== > Uh, Uh...no way. I have used both, and JR-Comm Zmodem is MUCH faster. Maybe your lines are noisy. ************************************************************************** * -Joseph Hillenburg (Sultan of Asm) * "Those are't bugs!" * * Addresses: * "Just undesirable features!"-Me * * INET: joseph@valnet.uucp ************************************* * UUCP: ...!iuvax!valnet!joseph * Call CompSci BBS * 1-812-873-440 * * MAIL: 1709 West Gray * 3/12/24 *9:30pm-7:30amEST* * MAIL: Bloomington, Indiana ************************************* * MAIL: 47401 United States * Amiga is king, and you can't * * Mail replies requested * tell me any different! * **************************************************************************
jprad@faatcrl.UUCP (Jack Radigan) (08/21/90)
arc@desire.wright.edu writes: > Jack, I have used your JRComm for a while now, and find it very nice. About >the internal ZModem, I don't find it that efficient... I have used NComm 1.9 >with it's external ZModem, and it takes MUCH less CPU time (I used XOper, plus >by doing some mtasking, etc.) for all xfering. I run your term at a 0 >priority, just as I do NComm 1.9 (NComm 1.9 is buggier than JRComm 1.0), but >the Zmodem library does an AWSOME job. I will be uploading with JRComm 1.0 at >a 0 priority (on its own screen) and then when I go to resize a window on my >workbench screen (interlaced) your term pause the transmit for a split >second... This really bothered me that you'd say that an external ZModem >wouldn't achieve the thoughput that your internal does... Well, since you asked... My tests were conducted between a 25MHz A3000 w/4M SCRAM and an A1000 w/'010 and 4M reg. RAM. All transfers were done to and from RAM: using ZMODEM, no handshaking with a null modem. With XOPER running, 4800bps was the highest speed that would complete a file transfer without errors, cpu utilization was at 100%. JR-Comm averaged about 43% with 38 and 50 as the extremes. NCOMM averaged about 51% with extremes of 47 and 63. Both of these transfers were at 4800bps using a 162k file with ZMODEM receive. Additionally, JR-Comm was using an 8 color screen to match screen DMA with NCOMM. So, on the whole, cpu usage was 10 points lower with JR-Comm than with NCOMM. But, cpu utilization was *not* what I was refering to, "throughput" was. And, throughput is best shown with uploads since you can only receive as fast as it is sent to you. NCOMM can transmit at only 1573cps @ 19.2kbps, or about 81.9% throughput. On the other hand, JR-Comm gets 1850cps, about 96.35% efficiency. NCOMM doesn't include 38.4kbps, so I couldn't test it at that rate. It's probably better that way too, considering that it is already almost 15 points behind JR-Comm. Who knows how much slower it would be then the 3600cps that JR-Comm obtains at that rate... Now, all this is really only of value to those with high speed modems. But, the point remains. JR-Comm has the more efficient ZMODEM implementation. -jack-