home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
appleii
/
apple.bwr
< prev
next >
Wrap
Internet Message Format
|
2018-01-01
|
8KB
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 <MEDIN-T@SHARK.nosc.mil>
Subject: Re: Apple II Kermit question
The lazer 128 must use the microtek serial port driver. Not the apple com
driver.
------------------------------
From: David Wilson <david@uow.edu.au>
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 <david@uow.edu.au>
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