APPLE@UMD2.UMD.EDU (Dick Atlee) (08/04/87)
I've enjoyed watching the ongoing melee of info-apple since I finally pulled
myself out of the water and onto the boat, with the help of Murphy Sewall
(luckily we have a direct arpa link here--I'm not nearly as tenacious as
Murphy in pursuing access rights). I'm Dick Atlee (in case I'm lost above
in one of those 50%-of-message-length "inside addresses" as we were taught
to call them in grammer school), from the University of Maryland Computer
Science Center. I wrote/am-writing the "other" Apple Kermit (non-3.7x),
and have finally got it just about to the point where I'd like to put it
up officially at Columbia. One nagging problem has dogged my tracks,
however, which has remained unsolved in spite of consultations with the
wizards of the Washington Apple-Pi users group and Bill Basham of
Diversidos fame. I present it here in the hopes that someone who still
remembers the golden days of DOS 3.3 might have an answer.
This particular Kermit behaves very nicely on IIe's and IIc's, and works
fine on a II+ after a certain point. That point is the one at which a
CONNECT command is issued to establish a connection. At this point, a II+
will generally (though not always) re-BRUN the Kermit program, which, if
a new disk has meanwhile been placed in the drive for file transfer,
creates all kinds of breast-beating on the part of DOS. If KERMIT is
started with a BLOAD/CALL sequence, the problem does not occur. All the
characteristics of the problem point toward DOS suddenly executing the
last command it received. However, the DOS and KERMIT are identical in
both cases--the only difference is II+ vs. post-II+, presumably the
Monitor ROMs. I have searched listings of these and have yet to find
anything that rings a bell. I realize the impossibility of debugging
someone's work over a network, but what I am asking is whether any of you
old-timers (or conservative new-timers) have ever stumbled on a discussion
of this sort of problem. I would VERY much appreciate help in solving this
thorn in my side. Thanks.
Dick Atlee
Arpa: APPLE@UMD2.UMD.EDU
Bitnet: ATLEE@UMDCkamath@reed.UUCP (Sean Kamath) (08/06/87)
I don't know why it's happenning on a plus and not an e or c, but for a
good little discussion of DOS 3.3 and BRUN, read the June '86 issue of
Apple Assembly Line. TO sumerize, there is a problem in the way DOS 3.3
calls a program when it is brun. THis is typically only a problem with
input/output.
In anycase, here's a really dandy way to simulate a BRUN.
?CHR$(4);"BLOAD FOO"
CALL 41876
Note, this is for 48K DOS 3.3 only.
BTW, don't get good 'ol DOS 3.3 mixed up with, you guessed it! PC DOS 3.3!
Till they get to 3.4, be careful reading the trade mags!
Sean Kamath
PS UUCP is truely a screwed up thing. I have to grub around through
the maps a lot to get to people. Once you get to psuvax1 or another
gateway, you can get anywhere -- provided you know how.
--
UUCP: {decvax allegra ucbcad ucbvax hplabs ihnp4}!tektronix!reed!kamath
CSNET: reed!kamath@Tektronix.CSNET || BITNET: reed!kamath@Berkeley.BITNET
ARPA: tektronix!reed!kamath@Berkeley <or> reed!kamath@hplabs
US Snail: 3934 SE Boise, Portland, OR 97202 (I hate 4 line .sigs!)