Sullivan@cup.portal.com (sullivan - segall) (07/14/90)
For those interested in the new release of John Radigan's terminal program, it seems to have finally been released. (I downloaded my review copy from Jay Miner's BBS415-967-2021.) First off, JrComm is arguably the most buggy software ever released on the Amiga market. Ultracard came close, but would at least get past its title screen before crashing. JrComm can't even seem to manage that much. Using a VT100 four color screen, an internal modem, and other such commonplace options, JrComm dies with a doubly freed structure (Guru 8100 0008 at 2BC7D0.) In fact I haven't been able to find a single default configuration other than the initial start up on the workbench that doesn't crash this program. The review-copy limitation is designed to be a nuisance. Actually it is quite effective. After having to rebuild my default files several times (because although I could engage VT100 emulation mode, I could not boot into it, thereby requiring that I rename the old defaults before trying to adjust them) the protection annoyed me enough to fall back to an earlier revision. To describe it simply, everytime you select something from the menu, there is a chance that you will be greeted with a message. Generally the messages point out all of the great advantages of registering your copy of the program, (except the first screen which is broken) and how these silly messages will go away when you do. JrComm 1.0 is also given to locking up. Generally this is accomplished by entering a state where the cursor is still flashing and the modem is still communicating, but the menues are forever lost. Not too bad if all you wanted was a straight VT100 (or TTY, or SKYTERM, or Amiga) terminal, but a little shy of the downloads, dialing, palettes, and reconfigurability I had hoped for. On the brighter side, many bugs have been eliminated in this version. JrComm 1.0 seems to be very stable changing from one screen format to another. And compared to version .94, a goodly number of options have been added. Just to highlight a few: * SkyTerm (if that's your bag) * All sorts of filters, optimized scrolls, smooth scroll, VT-100 improvements, and general terminal configurability * Exit without a query * Split review * Audible beep integrated into the Program * Several new Zmodem options What I'd still like to see: * Something a little more robust * Row and column counters on the status line * Row and column limits (ie 80 x 25) also * The ability to limit rows and columns (even if my workbench is morerowed, I don't neccessarily want my terminal to be non-standard.) * The ability to reset the text to default output modes. (There is a clearscreen option that does NOT do this correctly.) And of course in my dream-land there is also ARexx support without which I can't write scripts. JRComm lives in a sort of unusual netherworld between the gratuitous complexity of commercial communications packages, and the featureless public domain. JrComm 1.0 could easily be the finest terminal program available for shareware for any machine, but is limited by its roughness, and its lack of a defineable market niche. For all that JrComm has going for it, I truly hope that the rough corners will be smoothed out. I'll be waiting anxiously for 1.1. -kls
jma@beach.cis.ufl.edu (John 'Vlad' Adams) (07/15/90)
"Interesting comments..." I've been using 1.0 for a few days now in conjunction with two VT100 connections and eight IBM ANSI connections. I've yet to have a problem. Jack even has the 16 color IBM ANSI finally working flawlessly in regards to PAL -hacked Amigas. Zmodem works fine (unlike some bugs throughout the .99's). I've not tried any of the other protocols since Xmodem is too slow and I don't have an HST to take advantage of the Ymodem-G protocol. My wishes for the next JrComm - Kermit and AREXX port. I hate turning off DTR, dropping into VT100 to do Kermit transfers, and then popping back into JrComm to dial other BBS's. Good job, Jack. Newsgroups: comp.sys.amiga Subject: Re: JrComm 1.0 Summary: Expires: References: <31705@cup.portal.com> Sender: Reply-To: jma@beach.cis.ufl.edu (John 'Vlad' Adams) Followup-To: Distribution: na Organization: UF CIS Department Keywords: -- John M. Adams --**-- Professional Student on the six-year plan! /// Internet: jma@beach.cis.ufl.edu -or- vladimir@maple.circa.ufl.edu /// "We'll always be together, together in electric dreams" Tangerine Dream \\V// Cosysop of BBS:42; Amiga BBS FIDOnet 1:3612/42. 904-438-4803 (Florida) \X/
arc@desire.wright.edu (07/15/90)
In article <23847@uflorida.cis.ufl.EDU>, jma@beach.cis.ufl.edu (John 'Vlad' Adams) writes: > "Interesting comments..." I've been using 1.0 for a few days now > in conjunction with two VT100 connections and eight IBM ANSI > connections. I've yet to have a problem. Jack even has the 16 color > IBM ANSI finally working flawlessly in regards to PAL -hacked Amigas. > Zmodem works fine (unlike some bugs throughout the .99's). I've not > tried any of the other protocols since Xmodem is too slow and I > don't have an HST to take advantage of the Ymodem-G protocol. > > My wishes for the next JrComm - Kermit and AREXX port. I hate turning > off DTR, dropping into VT100 to do Kermit transfers, and then popping > back into JrComm to dial other BBS's. > > Good job, Jack. I ALSO wish SOMEONE would make some type of handler or a term that makes the "color flicker" on 4+ color screens stop. You know, the flickering you get when doing ANSI when it tries to scroll the screen? > Followup-To: > Distribution: na > Organization: UF CIS Department > Keywords: > > -- > John M. Adams --**-- Professional Student on the six-year plan! /// > Internet: jma@beach.cis.ufl.edu -or- vladimir@maple.circa.ufl.edu /// > "We'll always be together, together in electric dreams" Tangerine Dream \\V// > Cosysop of BBS:42; Amiga BBS FIDOnet 1:3612/42. 904-438-4803 (Florida) \X/
LordBah@cup.portal.com (Jeffrey J Vanepps) (07/15/90)
JR-Comm 1.0 is working beautifully for me. Nothing I've done has been able to break it. I've only had one lockup, probably due to running out of chip memory when I had JR-Comm, PKAZIP, C-Robots, interlaced morerowsed workbench, and a few other things all running at once (I still have the "slim" chip, haven't gotten fat yet). Of course, this is a registered copy, obtained from the author on a floppy. Someone might have gotten to the distributable copy that the first poster was running.
mcmahan@netcom.UUCP (Dave Mc Mahan) (07/16/90)
In a previous article, jma@beach.cis.ufl.edu (John 'Vlad' Adams) writes: >"Interesting comments..." I've been using 1.0 for a few days now >in conjunction with two VT100 connections and eight IBM ANSI >connections. I've yet to have a problem. Jack even has the 16 color >IBM ANSI finally working flawlessly in regards to PAL -hacked Amigas. >Zmodem works fine (unlike some bugs throughout the .99's). I've not >tried any of the other protocols since Xmodem is too slow and I >don't have an HST to take advantage of the Ymodem-G protocol. I got my copy of 1.0 via the mail, and have tried to install it. In the first call to the first BBS I use to read usenet, I find that the VT100 mode does not seem to properly handle inverse video. It prints a line, but with a character set that is black-on-black. I dropped back to version .99n, which I now use to write this message. Is this black-on-black problem a configuration error on my part, or is there something wrong with JR-Comm 1.0? I'd really like to use it instead of an older version, but I need at least some minimal functionality of the inverse video stuff for my mailer. Any suggestions out there? Personally, I happen to think that JR-Comm is optimal for my needs, if I could just get certain minor features to work correctly. I'd love to standardize on version 1.0 if I could get it to work. >John M. Adams --**-- Professional Student on the six-year plan! /// -dave
Sullivan@cup.portal.com (sullivan - segall) (07/16/90)
>> >> My wishes for the next JrComm - Kermit and AREXX port. I hate turning >> off DTR, dropping into VT100 to do Kermit transfers, and then popping >> back into JrComm to dial other BBS's. >> >> Good job, Jack. > > I ALSO wish SOMEONE would make some type of handler or a term that makes the >"color flicker" on 4+ color screens stop. You know, the flickering you get >when doing ANSI when it tries to scroll the screen? > Actually that has been improved for version1.0 (and maybe before, I don't really remember.) Rather than double buffering the display (a pretty expensive way to stop the color separation) John is using a color map that places all of the most commonly used colors and backgrounds in separate bits of the bitplane. That way the effect only becomes apparent for unusual combinations. This is IMHO a really neat way to approach the problem. (I kind of wish I'd thought of it myself.) -kls -Sullivan Segall _________________________________________________________________ /V\ Sullivan was the first to learn how to jump without moving. ' Is it not proper that the student should surpass the teacher? To Quote the immortal Socrates: "I drank what?" -Sullivan _________________________________________________________________ Mail to: ...sun!portal!cup.portal.com!Sullivan or Sullivan@cup.portal.com
mab@druwy.ATT.COM (Alan Bland) (07/16/90)
In article <31705@cup.portal.com> Sullivan@cup.portal.com (sullivan - segall) writes: >First off, JrComm is arguably the most buggy software ever released >on the Amiga market. Ultracard came close, but would at least get >past its title screen before crashing. JrComm can't even seem to >manage that much. [ description of JRcomm 1.0 bugs deleted ] I've been using JRcomm 1.0 for nearly a week now, several hours a day, switching between VT-100 and IBM color modes, and haven't seen any of the problems you describe. The only problem I've had is with line-wrap in VT-100 mode, and that may be a function of the UNIX terminfo entry I'm using or bugs in the UNIX programs. I've never seen any VT-100 emulator for the Amiga work completely correctly with every UNIX program I use). There is a note on Radigan's BBS that there is indeed a problem using 1.0 with a 2091 controller, causing a guru at some point. I don't have that configuration, so I didn't pay attention to the details, but you might try calling his BBS to find out the real scoop: 609-625-2453. -- -- Alan Bland -- att!druwy!mab == mab@druwy.ATT.COM -- AT&T Bell Laboratories, Denver CO -- (303)538-3510
grx1042@uoft02.utoledo.edu (Steve Snodgrass) (07/16/90)
In article <31705@cup.portal.com>, Sullivan@cup.portal.com (sullivan - segall) writes: > First off, JrComm is arguably the most buggy software ever released > on the Amiga market. Ultracard came close, but would at least get .. > Using a VT100 four color screen, an internal modem, and other such > commonplace options, JrComm dies with a doubly freed structure > (Guru 8100 0008 at 2BC7D0.) In fact I haven't been able to find .. > JrComm 1.0 is also given to locking up. Generally this is accomplished I don't know what the hell you've been doing with it, but I've been using JR-Comm 1.0 in VT100 and other modes with no problems whatsoever, on various types of screens. Neither has it ever locked up on me. Perhaps you should search for a cause on your end, before blaming the program. By the way, for those interested, 1.0 is available for FTP on ux1.cso.uiuc.edu. Steve Snodgrass - Ph'ran |SUBTEC - Student Union Board Technical Services| Green Rider of Telgar Weyr|Turbosound - the only way to fly. TMS-4 | --------------------------|-----------------------------------------------| GRX1042@uoft02.utoledo.edu|"It had limited capability, with a mere hundred| GRX1042@uoft02.BITNET | thousand gigabytes of RAM" -Jack L. Chalker | "Who explains the dreams we know/Carry us through from day to day" -me
leeg@mcrware.UUCP (Lee Glen) (07/16/90)
In article <833.26a02388@desire.wright.edu> arc@desire.wright.edu writes: >In article <23847@uflorida.cis.ufl.EDU>, jma@beach.cis.ufl.edu (John 'Vlad' Adams) writes: >> "Interesting comments..." I've been using 1.0 for a few days now >> in conjunction with two VT100 connections and eight IBM ANSI >> connections. I've yet to have a problem. Jack even has the 16 color >> >> John M. Adams --**-- Professional Student on the six-year plan! /// Well, I do. The neat "JRComm" screen will display, fade out, then give me the A3000 equivalent of a GURU telling me I have no more memory. What gives?
jprad@faatcrl.UUCP (Jack Radigan) (07/17/90)
Sullivan@cup.portal.com (sullivan - segall) writes: >Using a VT100 four color screen, an internal modem, and other such >commonplace options, JrComm dies with a doubly freed structure >(Guru 8100 0008 at 2BC7D0.) In fact I haven't been able to find >a single default configuration other than the initial start up on >the workbench that doesn't crash this program. An 81000008 is, according to the alerts.h header, a semaphore corrupt guru. It seems to be happening with systems that have a 2091 or when you use a custom screen *and* also change the priority of th task during startup. Why this guru occurs when both a custom screen *and* you change priority at the same time is currently beyond me. If you just change the screen or just change the priority this guru does not occur, very strange. >JrComm 1.0 is also given to locking up. Generally this is accomplished >by entering a state where the cursor is still flashing and the modem is >still communicating, but the menues are forever lost. Not too bad if >all you wanted was a straight VT100 (or TTY, or SKYTERM, or Amiga) >terminal, but a little shy of the downloads, dialing, palettes, >and reconfigurability I had hoped for. Could you please give me some sequence of events so that I can try to duplicate this? I've not had this reported before. >What I'd still like to see: > * Something a little more robust I'm working on it, promise! :-) Seriously, I'm quite embarrased about the problems that remain. > * Row and column counters on the status line > * Row and column limits (ie 80 x 25) also > * The ability to limit rows and columns (even if my > workbench is morerowed, I don't neccessarily want > my terminal to be non-standard.) Hmm, doable. > * The ability to reset the text to default output > modes. (There is a clearscreen option that does > NOT do this correctly.) Do you mean a VT100 reset? For the moment, opening the terminal requester does this. (I know, something "better"...). >And of course in my dream-land there is also ARexx support without >which I can't write scripts. Yes, eventually this too. >JRComm lives in a sort of unusual netherworld between the gratuitous >complexity of commercial communications packages, and the featureless >public domain. JrComm 1.0 could easily be the finest terminal program >available for shareware for any machine, but is limited by its roughness, >and its lack of a defineable market niche. Uh, thanks. (I guess)... :-) >For all that JrComm has going for it, I truly hope that the rough >corners will be smoothed out. I'll be waiting anxiously for 1.1. 1.01 will be a bug fix, 1.1 will add XPR. Scripts and ARexx somewhat farther down the road. Fair enough? -jack-
Radagast@cup.portal.com (sullivan - segall) (07/17/90)
>> First off, JrComm is arguably the most buggy software ever released >> on the Amiga market. Ultracard came close, but would at least get >.. >> Using a VT100 four color screen, an internal modem, and other such >> commonplace options, JrComm dies with a doubly freed structure >> (Guru 8100 0008 at 2BC7D0.) In fact I haven't been able to find >.. >> JrComm 1.0 is also given to locking up. Generally this is accomplished > >I don't know what the hell you've been doing with it, but I've been using >JR-Comm 1.0 in VT100 and other modes with no problems whatsoever, on various >types of screens. Neither has it ever locked up on me. Perhaps you should >search for a cause on your end, before blaming the program. > I did search for it on my end to some degree before writing the review. At the time I felt it was sufficient indication that only jrcomm of all the programs I run crashes regularly under these circumstances. But at your request I went back and rechecked. With a minimum of mounts and assigns it still crashes. With my morerowed interlaced workbench back to defaults it still crashes. That's it. There isn't anything else running. I'm not about to pull out my harddrive to see if it doesn't like that, or my internal modem, or my extra memory. It isn't worth it. The program is broken, kaput. I'd like to know how you manage to get it to run! For the curious: ----- cut here ----- begin 777 jrcomm.def M=#UN>GC&?`$2-*RE&XSOWF)X[SEZ3QD`-KAXQGP!=#UN>DU7LF"`]R;````1I MWP`!```````*``!```````$!`0`!```!``$!`0````E@``/0D`````@!````' M``````````````````````````````^0```+4```#Y````M0```/D```"U``N M`*JJJJJJJ@`!`````P0``````0````(```````````$!``````````@```!0A M`0$``0$```$!``$&``!!5%I>37Y^?D%413$@43`@5C$@6#1>30``````````+ M````````````````````````````````````````````````````````````` M````````051$5```````````````````````````````````````````````M M`````````$%41%0`````````````````````````````````````````````M M``````````!!5$14````````````````````````````````````````````M M````````````051$5```````````````````````````````````````````M M`````````````'Y^?BLK*WY^?D%42%Y-``````````!>30``````````````H M````````````3TL``````````````````````````$)54UD`````````````= M``````````!224Y'````````````````````````15)23U(`````````````Z M`````````%9/24-%``````````````````````!#3TY.14-4````````````` M````````3D\@0T%24DE%4@```````````````$Y/($1)04Q43TY%````````2 M``````````E@````E@`H`````0``````````"[L`"@H`"F``H`H*`*H&9@__$ M``\/``_P`/`/#P#_`!L````>`"``+0```&P`/`"'`!4`(````)@````%````Q M@``#`%4`!@!\`$```````/\`1`"1`!D```````````-I;CH(8V]M;3IO=70%F M8V]M;3H"4SH*:G)C;VUM+FQO9PUJ<F-O;6TN<&AO;F5S#6IR8V]M;2YM86-RM =;W,*:G)C;VUM+F-A<`UM;V1E;3`N9&5V:6-E``!OR `` end ---- end of cut --- also I incorrectly named the GURU # in the preceeding text. It should have read (8100 0008 "Semaphore corrupt"). It is quite consistent> -Sullivan Segall (a.k.a. Radagast) _________________________________________________________________ /V\ Sullivan was the first to learn how to jump without moving. ' Is it not proper that the student should surpass the teacher? To Quote the immortal Socrates: "I drank what?" _________________________________________________________________ Mail to: ...sun!portal!cup.portal.com!radagast or radagast@cup.portal.com
jprad@faatcrl.UUCP (Jack Radigan) (07/17/90)
arc@desire.wright.edu writes: > I ALSO wish SOMEONE would make some type of handler or a term that makes the >"color flicker" on 4+ color screens stop. You know, the flickering you get >when doing ANSI when it tries to scroll the screen? I'm going to try doing something along these lines. Although it will be totally asocial with respect to Intuition, there's got to be some way to do this... -jack-
jprad@faatcrl.UUCP (Jack Radigan) (07/17/90)
mcmahan@netcom.UUCP (Dave Mc Mahan) writes: >I got my copy of 1.0 via the mail, and have tried to install it. In the first >call to the first BBS I use to read usenet, I find that the VT100 mode does >not seem to properly handle inverse video. It prints a line, but with a >character set that is black-on-black. I dropped back to version .99n, >which I now use to write this message. Is this black-on-black problem >a configuration error on my part, or is there something wrong with JR-Comm 1.0? Did you re-install the fonts for VT100? They changed from the beta/gamma versions due to a problem with redrawing inverse characters when a font change was made to a previous line. -jack-
jprad@faatcrl.UUCP (Jack Radigan) (07/17/90)
Sullivan@cup.portal.com (sullivan - segall) writes: >Actually that has been improved for version1.0 (and maybe before, I >don't really remember.) Rather than double buffering the display (a >pretty expensive way to stop the color separation) John is using a >color map that places all of the most commonly used colors and backgrounds >in separate bits of the bitplane. That way the effect only becomes >apparent for unusual combinations. This is IMHO a really neat way to >approach the problem. (I kind of wish I'd thought of it myself.) -kls Ah! Does this mean there's hope for me yet? ;-) -jack-
jprad@faatcrl.UUCP (Jack Radigan) (07/17/90)
leeg@mcrware.UUCP (Lee Glen) writes: >Well, I do. The neat "JRComm" screen will display, fade out, then give me the >A3000 equivalent of a GURU telling me I have no more memory. What gives? This same guru is occuring with the CompuServe program Whap! vers. 1.9a. What release of 2.0 are you using? I don't have access to an A3000 except for casual testing at a local dealer and I suspect they haven't installed or received to install, the latest beta of 2.0 since I don't see this guru on that machine. -jack-
olson@donald.uhcc.Hawaii.Edu (Todd Olson) (07/17/90)
In article <1494@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: >leeg@mcrware.UUCP (Lee Glen) writes: > >>Well, I do. The neat "JRComm" screen will display, fade out, then give me the >>A3000 equivalent of a GURU telling me I have no more memory. What gives? > >This same guru is occuring with the CompuServe program Whap! vers. 1.9a. >What release of 2.0 are you using? I don't have access to an A3000 except >for casual testing at a local dealer and I suspect they haven't installed or >received to install, the latest beta of 2.0 since I don't see this guru on >that machine. This, a 82011234.00FC0834 out of memory guru, when I was running JRComm with the skypics termal in pal mode when the remote system sent a sound file. I would assume it was a bug in JRComm as I have 7 megs and JRComm was the only major program running. Todd Olson > > -jack- -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/ | "Take your work seriously, but never take \/ /\ olson@uhunix.uhcc.hawaii.edu | yourself seriously and do not take what /\ \/ olson@uhccux.uhcc.hawaii.edu | happens either to yourself or your work \/
sparks@corpane.UUCP (John Sparks) (07/17/90)
arc@desire.wright.edu writes: > I ALSO wish SOMEONE would make some type of handler or a term that makes the >"color flicker" on 4+ color screens stop. You know, the flickering you get >when doing ANSI when it tries to scroll the screen? This is due to a limitation in the blitter. It can only blit so much at a time, and in a large bitplane screen, it does the screen a couple bitplanes at a time which you see as color flicker. I think the new blitter in the ECS might be able to handle more screen memory per move and could eliminate the problem, but I am not sure. -- John Sparks | | D.I.S.K. 24hrs 2400bps. sparks@corpane.UUCP | | PH: (502) 968-DISK A door is what a dog is perpetually on the wrong side of. - Ogden Nash
terry@helios.ucsc.edu (Terry Ricketts) (07/17/90)
In article <619@cbnewsb.ATT.COM> mab@druwy.ATT.COM (Alan Bland) writes: > >There is a note on Radigan's BBS that there is indeed a problem using >1.0 with a 2091 controller, causing a guru at some point. I don't have >that configuration, so I didn't pay attention to the details, but you >might try calling his BBS to find out the real scoop: 609-625-2453. I also have been 'trying' to use Jr-Comm 1.0 for about a week now. I have a 2091 & that may be the problem. Could someone post the gist of the message on Jack's board. That is a long distance call from here. I have had no problems using 1.0 on local BBS's and in calling the Sun workstation at work using the VT100 emulation. BUT when I try to use 1.0 in conjunction with PCP_EZ to call via PC Pursuit 1.0 will completly freeze up. I have temporarily given up on it and am using Baud Bandit for PC pursuit calls. I also tried using PowerPacker 23b on JR-Comm 1.0 and it packed fine and would load and run ok when called from its own icon. But when called from within PCP_EZ it loaded and then dissapeared. This may not be a problem with 1.0 & Bill Fischer (author of PCP_EZ) is checking into it. He told me that he has been having problems with 1.0 as well. I sure hope some of this can get cleared up. I really like JR-Comm. It has the potential of being the greatest terminal program for the Amiga or any other computer with a little more work. I would like to echo another poster's comment that Kermit protocol and Arexx support are badly needed. Terry | Terry Ricketts | Internet: terry@helios.ucsc.edu | Senior Electronics Engineer | loel@helios.ucsc.edu | Lick Observatory Electronics Lab | Phone: 408-459-2110 | University of Calif, Santa Cruz |
yarnall@usceast.UUCP (Ken Yarnall) (07/18/90)
In article <619@cbnewsb.ATT.COM> mab@druwy.ATT.COM (Alan Bland) writes:
+
+There is a note on Radigan's BBS that there is indeed a problem using
+1.0 with a 2091 controller, causing a guru at some point. I don't have
+that configuration, so I didn't pay attention to the details, but you
+might try calling his BBS to find out the real scoop: 609-625-2453.
Well, I have not called Jack's BBS, but The copies of JRcomm I have had
contact with (A friend has a registered copy of 1.0, and I have a
distribution copy through him) both crashed quickly on machines equipped with
a 2091. By running a tiny little program I wrote to clear location zero, the
problem goes bye-bye. Being careful with those nasty NULL pointers?
Other than this (bad) problem, JRcomm 1.0 seems stable enough. I have
noticed some oddities about editing pallettes in the phonebook (If you are on
an 8 color screen, and you edit the pallette of a phonebook entry with a 4
color palllette, you are presented with an 8 color pallette requester).
Also, my jrcomm.phones file has disappeared twice now, forcing me to recreate
the whole thing. Ugh.
+-- Alan Bland
kenny
--
Ken Yarnall /// yarnall@cs.scarolina.EDU
Math Department, USC \\\/// yarnall@ucseast.UUCP
Columbia, S.C. 29208 \\\/ (803)777-6686jprad@faatcrl.UUCP (Jack Radigan) (07/18/90)
olson@donald.uhcc.Hawaii.Edu (Todd Olson) writes: >>This same guru is occuring with the CompuServe program Whap! vers. 1.9a. >>What release of 2.0 are you using? I don't have access to an A3000 except >>for casual testing at a local dealer and I suspect they haven't installed or >>received to install, the latest beta of 2.0 since I don't see this guru on >>that machine. > This, a 82011234.00FC0834 out of memory guru, when I was running JRComm >with the skypics termal in pal mode when the remote system sent a sound file. >I would assume it was a bug in JRComm as I have 7 megs and JRComm was the >only major program running. Like I said in the original post, this *same* gur occurs with Whap 1.9a as well, I'm not willing to agree that it is JR-Comm at this point since several people with severl meg of free ram are experiencing the same result with Whap! and 2.0. -jack-
Doug_B_Erdely@cup.portal.com (07/18/90)
Well, I guess its my turn to complain! :) Why o WHY! did jack waste time on Skypix graphics when we are STILL missing a very basic, yet important part of any term program on just about any computer? I am refering to scripts/ARexx port. I would rather see both, but just providing hooks into ARexx would be great! At this point this is the single reason WHY I have not registered/used JRComm. The idea being you register the software that does what you need. The program does not provide what *I* need, so that means $30 bucks less for Jack, simple! - Doug - Doug_B_Erdely@Cup.Portal.Com
jprad@faatcrl.UUCP (Jack Radigan) (07/18/90)
terry@helios.ucsc.edu (Terry Ricketts) writes: > I also have been 'trying' to use Jr-Comm 1.0 for about a week now. I have a >2091 & that may be the problem. Could someone post the gist of the message on >Jack's board. That is a long distance call from here. You have to run the 590FIX program or any little utility that resets memory location zero to 0. I still haven't been able to figure out what is doing this as MemGuard III does not report a low memory stomp on my A1000. More distressing is that when I stomp on location zero with ZeroMung, it continues to work fine on my A1000... Damndest thing I ever seen... > I have had no problems using 1.0 on local BBS's and in calling the Sun >workstation at work using the VT100 emulation. BUT when I try to use 1.0 in >conjunction with PCP_EZ to call via PC Pursuit 1.0 will completly freeze up. I >have temporarily given up on it and am using Baud Bandit for PC pursuit calls. Could you have Bill contact me? I'd like to work with him to determine the cause of this problem as well. -jack-
jprad@faatcrl.UUCP (Jack Radigan) (07/18/90)
Doug_B_Erdely@cup.portal.com writes: >Well, I guess its my turn to complain! :) Why o WHY! did jack waste time >on Skypix graphics when we are STILL missing a very basic, yet important >part of any term program on just about any computer? I am refering to >scripts/ARexx port. I would rather see both, but just providing hooks into >ARexx would be great! At this point this is the single reason WHY I have >not registered/used JRComm. The idea being you register the software that >does what you need. The program does not provide what *I* need, so that >means $30 bucks less for Jack, simple! Simple. There seemed to be a need at the time (over a year ago) for a Skypix emulation in a comm program that had more going for it then the bare minimum. Also, since the word had gotten out that ARexx was to be incorporated in Workbench 2.0, I figured that I would concentrate on the emulations and protocols first and then work on Scripts and Arexx afterwards. I also miss scripts and ARexx, and plan to correct that deficiency soon, but the fatc remains that the large body of comm users have little need for ARexx much less scripts, so I went the route I did. As for registering, do as you will, but if you're using the program with any regularity you *should* register. If not, no huuhuu. -jack-
papa@pollux.usc.edu (Marco Papa) (07/18/90)
In article <1500@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: >You have to run the 590FIX program or any little utility that resets memory >location zero to 0. I still haven't been able to figure out what is doing >this as MemGuard III does not report a low memory stomp on my A1000. More >distressing is that when I stomp on location zero with ZeroMung, it continues >to work fine on my A1000... Damndest thing I ever seen... Stomping on location 0 is a no-no for any application program. This is usually the result of an uninitialized pointer. I believe the hddisk device (or whatever it is called) for the A590 and A2091 assumed that nobody would stomp on location zero. I recall a message to that effect from CATS people a while back. -- Marco -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
kendrix_j@mims.enet.dec.com (John R. Kendrix) (07/19/90)
In article <1497@faatcrl.UUCP>, jprad@faatcrl.UUCP (Jack Radigan) writes... >olson@donald.uhcc.Hawaii.Edu (Todd Olson) writes: >> This, a 82011234.00FC0834 out of memory guru, when I was running JRComm >>with the skypics termal in pal mode when the remote system sent a sound file. >>I would assume it was a bug in JRComm as I have 7 megs and JRComm was the >>only major program running. > >Like I said in the original post, this *same* gur occurs with Whap 1.9a as >well, I'm not willing to agree that it is JR-Comm at this point since several >people with severl meg of free ram are experiencing the same result with Whap! >and 2.0. > > -jack- Hi Jack, I remember working with you on the above problem quite well when I was beta testing for you and Michael's Skyline. There were quite a few Sysops who had that problem with Skyline, turned out as you recall that there was a bug in Intuition which was causing the problem. The sysops who installed the patch FIXINTUITION ceased to have problems. Since this is occuring under 2.0, I wonder if they've fixed that bug yet in the OS... Good seeing your font again! Send me mail at the address below... JK ******************************************************************************** * John R. Kendrix c/o * Disclaimers: The opinions expressed here * * Digital Equipment Corporation * aren't likely to be claimed * * 5555 Windward Parkway * by me, much less my employer. * * Alpharetta, Ga. 30201 * * * 404-475-3379 * E-Mail: Kendrix_J@mims.enet.dec.com * ********************************************************************************
wizard@sosaria.imp.com (Chris Brand) (07/19/90)
First of all: Yes, I do pay my registration. It should go away in the next days. I just hope it reaches Jack.... I have the following problem with JRComm 1.0: When I choose IBM Color ANSI as Terminal, the Macros don't work anymore. I always get a ; when I press a function key. Why? -- ------------------------------------ Chris Brand - wizard@sosaria.imp.com "Justice is the possession and doing of what one is entitled to" - Platon ------------------------------------
mcmahan@netcom.UUCP (Dave Mc Mahan) (07/19/90)
In a previous article, yarnall@usceast.UUCP (Ken Yarnall) writes: >In article <619@cbnewsb.ATT.COM> mab@druwy.ATT.COM (Alan Bland) writes: >+ >Well, I have not called Jack's BBS, but The copies of JRcomm I have had >contact with (A friend has a registered copy of 1.0, and I have a >distribution copy through him) both crashed quickly on machines equipped with >a 2091. By running a tiny little program I wrote to clear location zero, the >problem goes bye-bye. Being careful with those nasty NULL pointers? Did you clear JUST location 0, or did you clear the 4 lowest bytes? >+-- Alan Bland -dave
umturne4@ccu.umanitoba.ca (Daryl Turner) (07/19/90)
In article <1990Jul15.200821.1117@uoft02.utoledo.edu> grx1042@uoft02.utoledo.edu (Steve Snodgrass) writes: >By the way, for those interested, 1.0 is available for FTP on >ux1.cso.uiuc.edu. Does ux1.cso.uiuc.edu support anonymous FTP through BITFTP? If so, would you mind giving the correct path to 1.0? (BITFTP is great, unless you have to go searching for something.) Daryl Turner <umturne4@ccu.umanitoba.ca>
yarnall@usceast.UUCP (Ken Yarnall) (07/20/90)
In article <12378@netcom.UUCP> mcmahan@netcom.UUCP (Dave Mc Mahan) writes: + + In a previous article, yarnall@usceast.UUCP (Ken Yarnall) writes: +>In article <619@cbnewsb.ATT.COM> mab@druwy.ATT.COM (Alan Bland) writes: +>+ +>Well, I have not called Jack's BBS, but The copies of JRcomm I have had +>contact with (A friend has a registered copy of 1.0, and I have a +>distribution copy through him) both crashed quickly on machines equipped with +>a 2091. By running a tiny little program I wrote to clear location zero, the +>problem goes bye-bye. Being careful with those nasty NULL pointers? + +Did you clear JUST location 0, or did you clear the 4 lowest bytes? I cleared the long word that starts at location 0. Here: main() { long *p; p = (long*) 0L; *p = 0L; } It works for me... + -dave kenny -- Ken Yarnall /// yarnall@cs.scarolina.EDU Math Department, USC \\\/// yarnall@ucseast.UUCP Columbia, S.C. 29208 \\\/ (803)777-6686
Doug_B_Erdely@cup.portal.com (07/20/90)
I do think you are underestimating the number of users that would like to see ARexx. I am glad you plan do to it, I have given some thought to making JR-Comm my main program (and registering it)... BUT, I want to make sure that I get a program with ARexx support. I am VERY careful about what I register fo my friend registered for Star Term and never heard a word from the gent who wrote that. I think he is a Compu$erve sysop. Consider me an admirer of JR-Comm, who is cautious. - Doug - Doug_B_Erdely@Cup.Portal.Com
papa@pollux.usc.edu (Marco Papa) (07/20/90)
In article <1508@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: >I'm fairly certain that it isn't a dereferenced NULL pointer that is causing >this since MemGuard III isn't complaining. Sorry Jack, BUT memGuard III won't be of much help since it can't catch a memory "read" on a A1000. You need a A2500, and 68020 or 68030 board with MMU (like Commodore A2620 or A2630) or an A3000 with Bryce's enforcer. [P.S.: I'm not saying that this is the reason for JRComm GURUs. Simply that you can't be sure it isn't until you have the appropriate tools] -- Marco -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
papa@pollux.usc.edu (Marco Papa) (07/20/90)
In article <1509@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: >papa@pollux.usc.edu (Marco Papa) writes: >>Stomping on location 0 is a no-no for any application program. This is >>usually the result of an uninitialized pointer. I believe the hddisk >>device (or whatever it is called) for the A590 and A2091 assumed that >>nobody would stomp on location zero. I recall a message to that effect from >>CATS people a while back. > >I'm aware of this already. What is weird is that I can't duplicate it with >ZeroMung on an A1000. A simple dereferenced pointer can be found with this >program, but not this semaphore guru. It's truely bizzare. Maybe I should have qualified 'stomping' as BOTH reading and writing location 0. On an A1000, ZeroMung & Co. will help you to find writing loc 0 problems. No way for you to find 'reading loc 0' problems. -- Marco -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
jprad@faatcrl.UUCP (Jack Radigan) (07/20/90)
yarnall@usceast.UUCP (Ken Yarnall) writes: >Well, I have not called Jack's BBS, but The copies of JRcomm I have had >contact with (A friend has a registered copy of 1.0, and I have a >distribution copy through him) both crashed quickly on machines equipped with >a 2091. By running a tiny little program I wrote to clear location zero, the >problem goes bye-bye. Being careful with those nasty NULL pointers? I'm fairly certain that it isn't a dereferenced NULL pointer that is causing this since MemGuard III isn't complaining. It manifested itself after adding the title screen during startup. I wonder if Intuition can't deal with closing one lores screen and immediately opening a custom hires screen behind it when location zero is set to a non-zero value. I have to write some example code to be sure of this though. >Other than this (bad) problem, JRcomm 1.0 seems stable enough. I have >noticed some oddities about editing pallettes in the phonebook (If you are on >an 8 color screen, and you edit the pallette of a phonebook entry with a 4 >color palllette, you are presented with an 8 color pallette requester). Hmm, the code *should* be only showing the first four colors, I'll have to check this again... >Also, my jrcomm.phones file has disappeared twice now, forcing me to recreate >the whole thing. Ugh. Could you try to find a sequence of events that causes this so that I can duplicate it? Thanks. -jack-
jprad@faatcrl.UUCP (Jack Radigan) (07/20/90)
papa@pollux.usc.edu (Marco Papa) writes: >Stomping on location 0 is a no-no for any application program. This is >usually the result of an uninitialized pointer. I believe the hddisk >device (or whatever it is called) for the A590 and A2091 assumed that >nobody would stomp on location zero. I recall a message to that effect from >CATS people a while back. I'm aware of this already. What is weird is that I can't duplicate it with ZeroMung on an A1000. A simple dereferenced pointer can be found with this program, but not this semaphore guru. It's truely bizzare. -jack-
jprad@faatcrl.UUCP (Jack Radigan) (07/20/90)
kendrix_j@mims.enet.dec.com (John R. Kendrix) writes: >I remember working with you on the above problem quite well when I was beta >testing for you and Michael's Skyline. There were quite a few Sysops who had >that problem with Skyline, turned out as you recall that there was a bug in >Intuition which was causing the problem. The sysops who installed the patch >FIXINTUITION ceased to have problems. Since this is occuring under 2.0, I >wonder if they've fixed that bug yet in the OS... Hmmm, I have to check on this. Thanks. >Good seeing your font again! Send me mail at the address below... You too! -jack-
jprad@faatcrl.UUCP (Jack Radigan) (07/20/90)
Doug_B_Erdely@cup.portal.com writes: >I do think you are underestimating the number of users that would like to >see ARexx. I am glad you plan do to it, I have given some thought to making >JR-Comm my main program (and registering it)... BUT, I want to make sure that >I get a program with ARexx support. I am VERY careful about what I register fo >my friend registered for Star Term and never heard a word from the gent who >wrote that. I think he is a Compu$erve sysop. Consider me an admirer of >JR-Comm, who is cautious. Your caution is well noted. I can't blame you for it either, considering your last experience. As for Arexx, it *will* be there, but it's going to take time as I have a real job to pay the bills and spend whatever spare time I can gather on JR-Comm. -jack-
jprad@faatcrl.UUCP (Jack Radigan) (07/20/90)
papa@pollux.usc.edu (Marco Papa) writes: >Sorry Jack, BUT memGuard III won't be of much help since it can't catch a >memory "read" on a A1000. You need a A2500, and 68020 or 68030 board with >MMU (like Commodore A2620 or A2630) or an A3000 with Bryce's enforcer. [P.S.: >I'm not saying that this is the reason for JRComm GURUs. Simply that you can't >be sure it isn't until you have the appropriate tools] Enforcer works with an A3000? I thought you posted that it wouldn't. Anyways, yes, I know that MenGuard III only groks writes, but all my pointer code writes after checking if the pointer is not NULL. Uh, at least I *think* so. Anyways, I have a tester who has access to the necessary machine to run the enforcer program and has located it to a system call, now we have to ferret out which call that is. I hope to post the results here tonight. -jack-
jprad@faatcrl.UUCP (Jack Radigan) (07/20/90)
papa@pollux.usc.edu (Marco Papa) writes: >Maybe I should have qualified 'stomping' as BOTH reading and writing >location 0. On an A1000, ZeroMung & Co. will help you to find writing loc 0 >problems. No way for you to find 'reading loc 0' problems. Think about this again. On a machine with a 2091 and a still stomped location zero, you get a semephore guru. If I stomp on location zero with a non-zero value using an A1000 and then run JR-Comm, it does not guru. This is what is so baffling. -jack-
phoenix@ms.uky.edu (R'ykandar Korra'ti) (07/21/90)
In article <2610@corpane.UUCP> sparks@corpane.UUCP (John Sparks) writes: >This is due to a limitation in the blitter. It can only blit so much at a time, >and in a large bitplane screen, it does the screen a couple bitplanes at a time >which you see as color flicker. Q: How about, instead of scrolling, say, two of four complete screen bitplanes at a time, scrolling four bitplanes for half the screen each time? You'd have a momentarily duplicated line, but it's a lot cheaper than double- buffering, no? - R'ykandar. -- | R'ykandar Korra'ti | Editor: LOW ORBIT Science and Fiction | PLink: Skywise | | Elfinkind, Unite! | phoenix@ms.uky.edu | phoenix%ms.uky.edu@ukcc.bitnet | | "Hi! We're evangelical Hari-Krishna pedophiles for LaRouche! Would you like | | to see some of our fine Amway products?" - TRHMS | CIS 72406,370/LOW ORBIT |
limonce@pilot.njin.net (Tom Limoncelli) (07/21/90)
In article <15664@s.ms.uky.edu> phoenix@ms.uky.edu (R'ykandar Korra'ti) writes: > In article <2610@corpane.UUCP> sparks@corpane.UUCP (John Sparks) writes: > Q: How about, instead of scrolling, say, two of four complete screen > bitplanes at a time, scrolling four bitplanes for half the screen each time? > You'd have a momentarily duplicated line, but it's a lot cheaper than double- > buffering, no? Didn't someone once post a message about allocating bitplanes in contiguous memory so that the entire scroll of 2-5 bitplanes could be done in one call to the blitter? It reduced this problem almost completely. The only problem was that you had to have a lot of contiguous memory. A program could try to allocate the memory that way and if it fails default to the "standard" method. (And a nice feature would be to make it possible to fail completely if it couldn't allocate it all in one shot). -Tom -- tlimonce@drew.edu Tom Limoncelli tlimonce@drew.uucp +1 201 408 5389 tlimonce@drew.Bitnet "You'd better move ovah limonce@pilot.njin.net ...here comes a supernova" -The B-52's.
papa@pollux.usc.edu (Marco Papa) (07/21/90)
In article <1517@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: |papa@pollux.usc.edu (Marco Papa) writes: ||Sorry Jack, BUT memGuard III won't be of much help since it can't catch a ||memory "read" on a A1000. You need a A2500, and 68020 or 68030 board with ||MMU (like Commodore A2620 or A2630) or an A3000 with Bryce's enforcer. [P.S.: ||I'm not saying that this is the reason for JRComm GURUs. Simply that you can't ||be sure it isn't until you have the appropriate tools] | |Enforcer works with an A3000? I thought you posted that it wouldn't. No, I didn't. The A3000 has an MMU, so it is the perfect machine for running Enforcer. At DevCon, one of the sessions done in the lab involved having developers trying their software with Enforcer. The lab was all A3000s. |Anyways, I have a tester who has access to the necessary machine to run the |enforcer program and has located it to a system call, now we have to ferret |out which call that is. I hope to post the results here tonight. Do you mean that indeed Enforcer finds a faulty 'read' access to low mem? -- Marco -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
papa@pollux.usc.edu (Marco Papa) (07/21/90)
In article <1518@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: >Think about this again. On a machine with a 2091 and a still stomped location >zero, you get a semephore guru. If I stomp on location zero with a non-zero >value using an A1000 and then run JR-Comm, it does not guru. This is what is >so baffling. In trying to duplicate the situation, I am assuming are you using the SAME value on location zero as on the A2091. Im I right? -- Marco P.S.: This looks like program debugging by Committee :-) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
jprad@faatcrl.UUCP (Jack Radigan) (07/22/90)
papa@pollux.usc.edu (Marco Papa) writes: >No, I didn't. The A3000 has an MMU, so it is the perfect machine for running >Enforcer. At DevCon, one of the sessions done in the lab involved having >developers trying their software with Enforcer. The lab was all A3000s. My mistake... >Do you mean that indeed Enforcer finds a faulty 'read' access to low mem? Yes, but from within a system call (this is with 2.0). I've still not had a return call from him yet. Hopefully this afternoon. -jack-
jprad@faatcrl.UUCP (Jack Radigan) (07/22/90)
papa@pollux.usc.edu (Marco Papa) writes: >In trying to duplicate the situation, I am assuming are you using the SAME >value on location zero as on the A2091. Im I right? <heavy sigh> No, will check again... >P.S.: >This looks like program debugging by Committee :-) Heheh, by the committee for the committed...
a63@mindlink.UUCP (Gary Coleman) (07/22/90)
Re: Arex/Scripting comming soon...Great. Gary Coleman, G.Coleman Concrete...:) (A happy customer)
john.russell@canremote.uucp (JOHN RUSSELL) (07/24/90)
Jack, for me JrComm would be head and shoulders above all the other terms around if not for one thing... the spritely cursor! All the little "while away the download" games like MiniBlast and Trix refuse to run if they can't grab the sprites they want. JrComm at least is nice enough to run even if one of these games does have the sprite allocated, but the lack of a cursor is inconvenient. Perhaps an option to select a "graphic" cursor or a "sprite" cursor? John --- * Via ProDoor 3.1R
ssd@sugar.hackercorp.com (Scott Denham) (07/24/90)
In article <31747@cup.portal.com>, LordBah@cup.portal.com (Jeffrey J Vanepps) writes: > JR-Comm 1.0 is working beautifully for me. Nothing I've done has been > able to break it. I've only had one lockup, probably due to running out > of chip memory when I had JR-Comm, PKAZIP, C-Robots, interlaced morerowsed > > Of course, this is a registered copy, obtained from the author on a > floppy. Someone might have gotten to the distributable copy that the > first poster was running. I missed the start of this thread, but I can report that JR-COMM 1.0 as I received it here appears to have some problems. I had 3 lockups in the first day of using it, all on a system using the SkyPix feature (thought for one of these lockups Skypix was NOT enabled). Subsequently to that I had two lockups in Z-Modem transfers - in both cases on the last block of a fairly large file. As a result I went back to 0.94, which has worked flawlessly for me for some time on the same system. Perhaps the memory requirments for 1.0 are signifigantly higher?? My system's a 1 megger, without much in the way of "extras" running.....
hychejw@ingr.com (Jeff W. Hyche) (07/27/90)
I'm posting for a friend. He uses Jrcomm 1.0 to call my bbs. He saids that after Jrcomm 1.0 connects he tries to use it to upload a file using Zmodem and the program after getting 20-40 sec into the upload it locks the system up. It doesn't guru it just locks up. It does it when he calles my bbs, it is running on metro 6.8. His system is an A1000 with a starboard II and a 68010 proccesser. Jeff Hyche Dragon's Haven (205) 722-0525 uunet!ingr!hychejw
jprad@faatcrl.UUCP (Jack Radigan) (07/31/90)
john.russell@canremote.uucp (JOHN RUSSELL) writes: >Jack, for me JrComm would be head and shoulders above all the other >terms around if not for one thing... the spritely cursor! >All the little "while away the download" games like MiniBlast and Trix >refuse to run if they can't grab the sprites they want. JrComm at least >is nice enough to run even if one of these games does have the sprite >allocated, but the lack of a cursor is inconvenient. >Perhaps an option to select a "graphic" cursor or a "sprite" cursor? At the time I wanted to provide a cursor that doesn't penalize the text output, a sprite was the best solution. Not being a gamer, I overlooked this problem. It's on my "todo" list (has been for awhile, just didn't get to it yet)... -jack-
arc@desire.wright.edu (07/31/90)
In article <f8a83f42041926abc9dc@canremote.uucp>, john.russell@canremote.uucp (JOHN RUSSELL) writes: > Jack, for me JrComm would be head and shoulders above all the other > terms around if not for one thing... the spritely cursor! > > All the little "while away the download" games like MiniBlast and Trix > refuse to run if they can't grab the sprites they want. JrComm at least > is nice enough to run even if one of these games does have the sprite > allocated, but the lack of a cursor is inconvenient. > > Perhaps an option to select a "graphic" cursor or a "sprite" cursor? > > John > --- > * Via ProDoor 3.1R Yes, I see your point, but, these other other games/hacks that use sprites COULD grab what they want if they were written properly. I'd like to see the cursor on JRComm 1.00 editable, and able to use a bitmap image instead of a sprite... ------------------------------------------------------------------------ = /// | 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 = ========================================================================
jprad@faatcrl.UUCP (Jack Radigan) (08/02/90)
arc@desire.wright.edu writes: > Yes, I see your point, but, these other other games/hacks that use sprites >COULD grab what they want if they were written properly. I'd like to see the >cursor on JRComm 1.00 editable, and able to use a bitmap image instead of a >sprite... Hmm, interesting idea. I could see this getting carried to an extreme though, wouldn't a bitmapped block ala the CLI be enough? Also, as I posted elsewhere, a bitmapped cursor can slow down text output somewhat. -jack-
David.Plummer@f70.n140.z1.FIDONET.ORG (David Plummer) (08/07/90)
I only got a cursory look at 1.0 (I believe I had the same font problem as the other guy), but I was wondering if 1.0 now supports the PF keys on the keypad under VT100 emulation. I'd love to be able to use JRCOMM more than I can. For now I'm limited to mostly Handshake for reasons of VT100 compatibility. Are there any plans to implement the keypad and the full Kermit (text included) protcol? -- David Plummer - via FidoNet node 1:140/22 UUCP: ...!alberta!dvinci!weyr!70!David.Plummer Domain: David.Plummer@f70.n140.z1.FIDONET.ORG Standard Disclaimers Apply...
jprad@faatcrl.UUCP (Jack Radigan) (08/10/90)
David.Plummer@f70.n140.z1.FIDONET.ORG (David Plummer) writes: >I only got a cursory look at 1.0 (I believe I had the same font problem >as the other guy), but I was wondering if 1.0 now supports the >PF keys on the keypad under VT100 emulation. Yes, the PF keys are supported. The numeric keypad on the A500 & A2000 (guess the A3000 as well) match the VT100 keypad exactly as long as the keymap usa1 is present (via SetMap). Don't know enough about WB 2.0 yet to comment on it. The A1000 lacks four of the keys that the others have so I mapped the first four fuction keys to the PF keys. You can override these defaults by declaring a macro for the corrosponding function key. >Are there any plans to implement the keypad and the full Kermit (text >included) protcol? As soon as I finish the 1.01 release I will begin work on 1.1 which will add XPR support. Kermit is more or less at the mercy of the capabilities of any Kermit XPR library. How many and how capable they are, I can't say, maybe someone else can. -jack-