Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!ucbvax!ISUMVS.BITNET!GA.NES From: GA.NES@ISUMVS.BITNET (SCHUESSLER) Newsgroups: comp.sys.apple Subject: (none) Message-ID: <8711222138.aa03063@SMOKE.BRL.ARPA> Date: Sat, 21-Nov-87 22:22:22 EST Article-I.D.: SMOKE.8711222138.aa03063 Posted: Sat Nov 21 22:22:22 1987 Date-Received: Wed, 25-Nov-87 21:03:13 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 78 I am having problems with Kermit 3.79 which the ISU micro- products center does not have the time nor interest to answer, so I would appreciate it if someone could help me... First I'll give a description of my setup: I have a ][e with a serial interface card from Practical peripherals { Apple Interface Card } and an ADC Hayes compatible 1200 baud modem. My most pressing problem is that I lose 2 or 3 characters at the beginning of every line when I am connected. I am using the Microtek driver since I think my interface isn't completely compatible with the Super Serial Card. (I was told to set interrupts with a switch, but my card has no switches). I've messed with the parity, the driver, echo/noecho, and almost everything I could think of, and I can't get it to work. What should I do? Before I continue I'd like to say that changing the driver from SSC (Super Serial Card) was not easy. On the Kermit 3.79 disk there exists KERMIT379, the main program, SAVEIT, and all the drivers named KER379.ex where ex is the extension of the particular card driver. Also included is an EXEC file named KERMIT.INSTALL. I tried for a long time to get the driver changed by EXEC'ING the appropriate files, but all I got was a bunch of syntax errors from BASIC, and then KERMIT with absolutely no change. I then figured out that The EXEC files were all in such a manner that the spaces and returns were removed making the whole EXEC file one big paragraph. (Boy was that hard to read!!) After a couple hours of separating the lines out again, I tried EXEC'ing it (KERMIT.INSTALL) again. It still didn't work. I decided to just run the driver install routine w/o KERMIT.INSTALL. The driver routine worked, but it called KERMIT.INSTALL afterwards, thus bringing me back to square one. I simply made sure KERMIT.INSTALL wasn't accessable on either drive (I have two drives), and when the driver routine was done EXEC'ing, I simply ran SAVEIT. That finally installed the Microtek driver. This brings me to my second problem with KERMIT. When I connect using VT100 emulation mode, I get a LOT of stray inverse characters (control characters) along with brackets and things (we're talking DEC VT100 sorry). Using it with any editor on VAX is pointless since it drops the cursor to the bottom of the screen, and jumps around when I type (the delete/backspace function when you make an error is also frusterating since the cursor jumps). What is going on, and how can I fix it ??? The MODEM command in KERMIT results in a ProDos error. Why? Reading in a file in ProDos is easy (comparably) in assembly code. (In fact, the MODEM command doesn't even go to the disk -- the error occurs before then.) Ok, let's get away from specific problems now, and let me pose a few other questions..... What is the difference between version 3.79 and 3.80 --- anything that may help me out? Does anyone know where one can get an assembly listing (documented would be preferred) to see the routines? I would think that a few routines would make KERMIT a little more user-friendly... Why couldn't the device driver installation be handled within the program rather than by manipulating EXEC files? Why not have an interactive set-up feature for adding new terminals to the list of ones emulated? Here at ISU (Iowa State University) we also have DEC VT240's and VT340's. A routine to define / redefine keystroke/ASCII values would be nice -- the up arrow, left arrow, etc don't send the right ASCII value(s) to do the equivalent function on the VT100. I think these features would make KERMIT a lot more useable. A note on the assembly listing--Am I correct in assuming that the routines for KERMIT were written on UNIX?? An assembly listing in 6502 code would be preferrable. At his point, I don't see why some others have had good reviews of KERMIT--I guess it is because of my troubles. I hope someone out there can help -- I suppose Ted Medin would be the one if he would see this letter. Thanks to anyone who can help (in advance). Niko Schuessler Lyon 221 Barker Iowa State University Ames Ia 50012 A SIDE NOTE: Michael Niehaus submitted mail explaining the same problem about the same time I did.