Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!houxm!houxz!vax135!cornell!uw-beaver!tektronix!hplabs!sri-unix!Mark%upenn.csnet@csnet-relay.arpa From: Mark%upenn.csnet@csnet-relay.arpa Newsgroups: net.emacs Subject: terminal driver innards Message-ID: <12243@sri-arpa.UUCP> Date: Wed, 8-Aug-84 21:56:00 EDT Article-I.D.: sri-arpa.12243 Posted: Wed Aug 8 21:56:00 1984 Date-Received: Sat, 11-Aug-84 06:46:01 EDT Lines: 37 From: Mark B. Reinhold While tuning the padding in a couple of our locally-written terminal drivers, I tried to figure out exactly what was going on in terms of padding and motion cost figures. Previously, I had just twiddled them until they worked. Can anyone answer the following questions? 1. I had thought that the BaudFactor was the number of characters to send to delay 1 millisecond. This would allow all padding computations to be done in terms of milliseconds. In trmc100.c, and in many other drivers distributed with #264, the BaudFactor is computed by the following formula: BaudFactor = BaudRate / ( (1 - (.45 + .3 * (BaudRate / 9600.))) * 10000.) (Actually, the above formula was used in trmc100.c in #85 as well). Why is it done this way? How is this formula obtained? 2. How does one compute the various cost factors (t_ILmf, t_ILov, etc.) in the TrmControl struct? trm.h claims the following: costs are expressed as number_affected*mf + ov cost to insert/delete 1 line: (number of lines left)*ILmf+ILov cost to insert one character: (number of chars left on line)*ICmf+ICov cost to delete n characters: n*DCmf+DCov Where I assume that the "cost" of an operation is the number of transmitted characters it would require (correct me if I'm wrong). Contrary to the comment, when the UpdateLine procedure in display.c uses ICmf, it doesn't multiply by the number of characters left on the line; it multiplies by the number of characters to be inserted. Is this a known problem? Any advice would be appreciated. Mark B. Reinhold Computer & Information Science Dept., University of Pennsylvania CSNet: mark@upenn ARPANet: mark%upenn@csnet-relay