Date: 12 JUN 91 11:07:58 From: PSYC223@UNLCDC2.BITNET Subject: kermit.laser.128 I received your address from the Computing Resources Center at the University of Nebraska. I am trying to use Kermit to make connection with the University mainframe; the computer is a Laser 128 (Apple IIc compatible) and the modem is a Zoom 2400R. When I enter the "CONNECT" command, I get an error message, requesting a reboot. Is it known whether Kermit works with Laser 128? If it does not work, are there modifications in the program that can make it compatible? If it does work, are there any special configurations or slot assignments that are not obvious? If you are not the person to whom I should direct these questions, I am sorry to bother you. If you know another person who might have this information, I would appreciate receiving an e.mail address for such assistance. Thanks. Dan Bernstein University of Nebraska psyc223@unlcdc2 ------------------------------ Date: Wed, 03 Jul 91 11:59:46 PDT From: Ted Medin Subject: Re: Apple II Kermit question The lazer 128 must use the microtek serial port driver. Not the apple com driver. ------------------------------ From: David Wilson Subject: Some fixes to Kermit-65 source Date: Mon, 12 Jan 1998 10:44:20 +1100 (EST) Attempting to build Kermit-65 on my Linux system (5x86-133 CPU, Redhat 4.2), I find that as65c02 is unable to assemble appmai.m65. Building the same program on Solaris for Sparc results in an assembler that has no problems with that module. Very strange - I wonder if as65c02 assumes that the system it runs on is big-endian? 3) A number of modules of Kermit-65 v3.87 do not assemble due to comments missing leading semi-colon. Here is a diff to fix them: *** appcps.m65.orig Mon Jan 12 10:20:34 1998 --- appcps.m65 Mon Jan 12 10:20:49 1998 *************** *** 20,28 **** ; ;$Log: appcps.m65,v $ ! Revision 1.5 90/10/15 14:19:59 medin ! new org for 3.87 of $7f00 ! version 1.4 ;Revision 1.4 88/12/22 09:25:02 medin ;use the time constant for the wait routine --- 20,28 ---- ; ;$Log: appcps.m65,v $ ! ;Revision 1.5 90/10/15 14:19:59 medin ! ;new org for 3.87 of $7f00 ! ;version 1.4 ;Revision 1.4 88/12/22 09:25:02 medin ;use the time constant for the wait routine *** appgs.m65.orig Mon Jan 12 10:21:09 1998 --- appgs.m65 Mon Jan 12 10:21:21 1998 *************** *** 19,27 **** ; ; $Log: appgs.m65,v $ ! Revision 1.7 90/10/15 14:21:04 medin ! new org for 3.87 of $7f00 ! version 1.6 ;Revision 1.6 89/11/06 11:42:28 medin ; Use xon/xoff or dtr but not both --- 19,27 ---- ; ; $Log: appgs.m65,v $ ! ;Revision 1.7 90/10/15 14:21:04 medin ! ;new org for 3.87 of $7f00 ! ;version 1.6 ;Revision 1.6 89/11/06 11:42:28 medin ; Use xon/xoff or dtr but not both *** apphmm.m65.orig Mon Jan 12 10:19:36 1998 --- apphmm.m65 Mon Jan 12 10:19:46 1998 *************** *** 18,26 **** ; ;$Log: apphmm.m65,v $ ! Revision 1.8 90/10/15 14:23:32 medin ! new org of $7f00 for 3.87 ! version 1.8 ;Revision 1.7 88/12/22 09:26:51 medin ;use the time constant for the wait routine --- 18,26 ---- ; ;$Log: apphmm.m65,v $ ! ;Revision 1.8 90/10/15 14:23:32 medin ! ;new org of $7f00 for 3.87 ! ;version 1.8 ;Revision 1.7 88/12/22 09:26:51 medin ;use the time constant for the wait routine *** appmsv.m65.orig Mon Jan 12 10:19:59 1998 --- appmsv.m65 Mon Jan 12 10:20:24 1998 *************** *** 18,26 **** ; ;$Log: appmsv.m65,v $ ! Revision 1.9 90/10/15 14:25:50 medin ! new org of $7f00 for 3.87 ! version 1.8 ;Revision 1.8 88/12/22 09:40:58 medin ;use time constant for the wait routine --- 18,26 ---- ; ;$Log: appmsv.m65,v $ ! ;Revision 1.9 90/10/15 14:25:50 medin ! ;new org of $7f00 for 3.87 ! ;version 1.8 ;Revision 1.8 88/12/22 09:40:58 medin ;use time constant for the wait routine *** appssc.m65.orig Mon Jan 12 10:19:11 1998 --- appssc.m65 Mon Jan 12 10:19:24 1998 *************** *** 22,30 **** .ifne 0 ; get around the revisions ; DONT FORGET TO UPDATE THE VERSION ;$Log: appssc.m65,v $ ! Revision 1.15 90/10/15 14:27:07 medin ! new org of $7f00 for 3.87 ! version 1.15 ;Revision 1.14 88/12/22 09:13:22 medin ;verison 1.14 changes for time count, input buffer now $900 and --- 22,30 ---- .ifne 0 ; get around the revisions ; DONT FORGET TO UPDATE THE VERSION ;$Log: appssc.m65,v $ ! ;Revision 1.15 90/10/15 14:27:07 medin ! ;new org of $7f00 for 3.87 ! ;version 1.15 ;Revision 1.14 88/12/22 09:13:22 medin ;verison 1.14 changes for time count, input buffer now $900 and -- David Wilson Sch of Informatics, Uni of Wollongong, Australia david@uow.edu.au ------------------------------ From: David Wilson Subject: A fix for problem in as65c02 unable to assemble kermit-65 Date: Wed, 14 Jan 1998 09:49:49 +1100 (EST) > > 2) Attempting to build Kermit-65 on my Linux system (5x86-133 CPU, > > Redhat 4.2), I find that as65c02 is unable to assemble appmai.m65. > > > Well, as you know it's not written in any standard assembler, as you have > discovered; it was originally written for a cross-assember called CROSS, that > ran on the PDP-10. Later, as I recall, it was ported to SunOS, but it gets > dim after that. In any case, the last guy who worked on Kermit-65 retired > several years ago, so you're kind of on your own. It turned out to be a simple problem - a buffer overrun. GDB's watch command was very useful in finding this. When built with gcc on Linux, the errcnt variable ends up just in front of the prlnbuf buffer. In the readline function we find the following code: i = 3; while (temp1 != 0) { /* put source line number into prlnbuf */ prlnbuf[i--] = temp1 % 10 + '0'; temp1 /= 10; } Note that appmai.m65 is 17698 lines in length. When the assembler reads line 10000, the code above writes a '1' into prlnbuf[-1] which destroys the errcnt variable. My fix for this: *** ass1.c.orig Wed Jan 14 09:44:27 1998 --- assm1.c Wed Jan 14 09:44:40 1998 *************** *** 153,159 **** temp1 = ++slnum; for (i = 0; i < LAST_CH_POS; i++) prlnbuf[i] = ' '; ! i = 3; while (temp1 != 0) { /* put source line number into prlnbuf */ prlnbuf[i--] = temp1 % 10 + '0'; temp1 /= 10; --- 153,159 ---- temp1 = ++slnum; for (i = 0; i < LAST_CH_POS; i++) prlnbuf[i] = ' '; ! i = 4; while (temp1 != 0) { /* put source line number into prlnbuf */ prlnbuf[i--] = temp1 % 10 + '0'; temp1 /= 10; Or, if you prefer to fix the shell archive: *** appxas.2.orig Wed Jan 14 09:46:02 1998 --- appxas.2 Wed Jan 14 09:46:17 1998 *************** *** 648,654 **** temp1 = ++slnum; for (i = 0; i < LAST_CH_POS; i++) prlnbuf[i] = ' '; ! i = 3; while (temp1 != 0) { /* put source line number into prlnbuf */ prlnbuf[i--] = temp1 % 10 + '0'; temp1 /= 10; --- 648,654 ---- temp1 = ++slnum; for (i = 0; i < LAST_CH_POS; i++) prlnbuf[i] = ' '; ! i = 4; while (temp1 != 0) { /* put source line number into prlnbuf */ prlnbuf[i--] = temp1 % 10 + '0'; temp1 /= 10; I do not think that we will ever need to support 100,000 line 6502 programs. -- David Wilson School of Informatics, University of Wollongong, Australia david@uow.edu.au