SECRIST%OAK.SAINET.MFENET@LLL-MFE.ARPA (04/30/85)
Dave Towson, et. al., thanks. I am the originator of the ADM3a/Kaypro termcap (or the one who POSTED it, anyway) that's been causing all of the hoop-lah. Perhaps the differences that were of consurn have something to do with the fact that I provided an EMACS termcap entry, and this was being compared and contrasted to a UNIX termcap. I can state that I have used this termcap on a Kaypro II with my own hands for hours on our VAX under VAX/VMS running a Gosling EMACS. As for the rest of the world, gee - I dunno. I hope it was of help, anyway. And if you need the EMACS termcap gobbledegook deciphered for you out there in netland, I will be happy to provide the EMACS interpretation for you to the best of my ability. As to UNIX - go find a UNIX person, I'm a VAX/micro hacker. Or a micro VAX-hacker. Or perhaps - uh, never mind. Best I not use VAX, UNIX, and hacker in sentences lest I let myself in for a flame. As to "tirades" and all of that, I am not upset - yet another flame in netland, as I see it - and probably quite useful if you are trying to get up on a UNIX system at that. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Richard Secrist * "It's always darkest just before it gets pitch black." -Anon.
wcwells%ucbopal.CC@ucb-vax.ARPA (William C. Wells) (04/30/85)
Some of you may have noticed differences in the padding number for "cl", eg. :cl=3^Z:, cl=1^Z . I suspect that some of the problems I have observed with the Kaypro 2x at higher port speeds (eg. 1200, 9600 baud) are related to needs for the microcomputer to do some work each time it receives a new-line (linefeed) and/or return (CR) character from a remote system. Depending on the port speed and the amount of cpu processing required by the communication program on the Kaypro, it may be necessary to increase the padding on "cl" (clear screen), and set or increase "dC" (number of milisec of cr delay needed) and "dN" (number of milisec of nl delay needed). Of course, adding padding and end of line delays to the termcap may not be the whole solution. Lack of data line flow control (eg. XOFF/XON) can easily bring most communications programs to a halt at higher speeds (by overflowing I/O buffers). In addition, many communication and file transfer program assume a quick response to transmission from the remote machine. That is, the program will time out when the required response is delayed, for example, by an overloaded time sharing system. Bill wcwells@Berkeley.ARPA