hull@hao.UUCP (Howard Hull) (10/15/86)
In article <305@pttesac.UUCP>, vanam@pttesac.UUCP (Marnix van Ammers) writes: > ... according to Wecker, the [VT100] program does > *not* leave DTR on. So now I've found that this thing that I thought > was a feature, actually only happens under certain circumstances. I'm > trying to isolate just when I get this feature. For some reason I > could not get the feature to work at all last night (DTR kept going off > when I quit the program) but I swear, the night before it was working > just as I've said: DTR remained on... Ah ha... I had the same sensation of inconsistency about Wecker's VT100 and the behavior of DTR dependent interfaces. I finally discovered that what I had done was to invoke another terminal program which doesn't reset DTR, quit that, and then fire up VT100. I read somewhere that the serial device keeps a cumulative count of the number of devices that have requested use of the port. Those that open the device properly increment the count, and those that close the device properly decrement the count. If you have a program that fails to close properly when it quits, then the device count is already at least one when VT100 starts up. Thus when VT100 quits, the count remains greater than zero and DTR remains asserted. However two things remain a mystery to me. The first is that I wonder why I can't blast the count to zero by repeatedly hitting the "hang up" menu option in the VT100 program. The second is the matter of the meaning of "Exclusive Use" of the port. It seems to me that if a program requests exclusive use of the port, and the count is already up by one, then the AmigaDOS response had ought to be to return an error for the dev Open call. I really have no idea what it does do, as I haven't yet had a chance to look at it. But as I say, I am beginning to wonder... Howard Hull [If yet unproven concepts are outlawed in the range of discussion... ...Then only the deranged will discuss yet unproven concepts] {ucbvax!hplabs | decvax!noao | mcvax!seismo | ihnp4!seismo} !hao!hull
chiu@princeton.UUCP (Kenneth Chiu) (10/16/86)
In article <257@hao.UUCP> hull@hao.UUCP (Howard Hull) writes: >. . .why can't [I] blast the count to zero by repeatedly hitting the "hang up" >menu option in the VT100 program[?]. . . My initial thinking was that hanging up would be implemented by closing the device for a short interval and then reopening. Thus the count would go back up. However, the source says: case 1: /* add hangup code here */ break; So obviously blasting "hang up" doesn't work. >. . .if a program requests exclusive use of the port, and the count is already >up by one, then the AmigaDOS response had ought to be to return an error for >the dev Open call. Yes, I agree. I couldn't find any specific information about this the manuals, but this seemed to be the implication. -- Kenneth Chiu UUCP: princeton!chiu Princeton University Computer Science Department BITNET: 6031801@PUCC
vanam@pttesac.UUCP (Marnix van Ammers) (10/17/86)
In article <257@hao.UUCP> hull@hao.UUCP (Howard Hull) writes: >In article <305@pttesac.UUCP>, vanam@pttesac.UUCP (Marnix van Ammers) writes: >> ... according to Wecker, the [VT100] program does >> *not* leave DTR on. So now I've found that this thing that I thought >> was a feature, actually only happens under certain circumstances. I'm >> trying to isolate just when I get this feature. For some reason I >> could not get the feature to work at all last night (DTR kept going off >> when I quit the program) but I swear, the night before it was working >> just as I've said: DTR remained on... > >Ah ha... I had the same sensation of inconsistency about Wecker's VT100 and >the behavior of DTR dependent interfaces. I finally discovered that what I >had done was to invoke another terminal program which doesn't reset DTR, >quit that, and then fire up VT100. I read somewhere that the serial device >keeps a cumulative count of the number of devices that have requested use >of the port. Those that open the device properly increment the count, and >those that close the device properly decrement the count. If you have a >program that fails to close properly when it quits, then the device count >is already at least one when VT100 starts up. Thus when VT100 quits, the >count remains greater than zero and DTR remains asserted. Howard is right. Just last night I discovered that when I use maxicomm first and then vt100, when I quit the vt100 program then DTR remains ON. Now I *think* (still need to check this out) that no matter how many times I run maxicomm, DTR is always turned off when I quit the program. Something doesn't quite make sense there. But no matter how many times I run vt100 after once having run maxicomm, DTR stays on when I quit. Since I like DTR to remain on most of the time (but not always!) I guess I can run maxicomm first. Seems like it must be possible to come up with a tiny little program that will do this for me. That makes it also possible to have a configurable (via vt100.init) DTR ON option. At least so I think. Marnix -- Marnix A. van\ Ammers Home: (707) 644-9781 Work: (415) 545-8334 {ihnp4|ptsfa}!pttesac!vanam CIS: 70027,70
hamilton@uiucuxc.CSO.UIUC.EDU (10/17/86)
hull@hao says: > If you have a > program that fails to close properly when it quits, then the device count > is already at least one when VT100 starts up. Thus when VT100 quits, the > count remains greater than zero and DTR remains asserted. > I wonder why I can't blast the count to zero by ... the "hang up" menu > option in the VT100 program. ... It seems to me that if a program requests > exclusive use of the port, and the count is already up by one, then the > AmigaDOS response had ought to be to return an error for the dev Open call. v2.1 vt100 didn't have any code to hangup; the menu item was there, but it didn't do anything. v2.2 has code to close the device, wait .75s, then re-open it, so the open count will remain unchanged afterward. if the open count is non-zero and vt100 requests exclusive access, the OpenDevice will fail. actually the logic is like this: if open count == 0 no problem; you got it else if current mode is "shared" and new mode is also "shared" you got it else open fails wayne hamilton U of Il and US Army Corps of Engineers CERL UUCP: {ihnp4,pur-ee,convex}!uiucdcs!uiucuxc!hamilton ARPA: hamilton%uiucuxc@a.cs.uiuc.edu USMail: Box 476, Urbana, IL 61801 CSNET: hamilton%uiucuxc@uiuc.csnet Phone: (217)333-8703 CIS: [73047,544] PLink: w hamilton
louie@sayshell.umd.edu (Louis A. Mamakos) (10/29/86)
> However two things remain a mystery to me. The first is that I wonder why > I can't blast the count to zero by repeatedly hitting the "hang up" menu > option in the VT100 program. The second is the matter of the meaning of > "Exclusive Use" of the port. It seems to me that if a program requests > exclusive use of the port, and the count is already up by one, then the > AmigaDOS response had ought to be to return an error for the dev Open call. > I really have no idea what it does do, as I haven't yet had a chance to > look at it. But as I say, I am beginning to wonder... > > Howard Hull > {ucbvax!hplabs | decvax!noao | mcvax!seismo | ihnp4!seismo} !hao!hull You can't zero the use count, because the "hang up" menu item can only close the serial.device, and then reopen it. You should not close the device more than once! If the use count was 2 before, after you close the device, it will drop to 1. If you request exclusive use of the device when you open it, the OpenDevice() will indeed fail if it is already open. Note that in this case, AmigaDOS is not involved at all, since you're using the low level device driver, not the SER: device. If another program is broken, and doesn't clean up after itself, fix it or stop using it. Don't try to kludge other (perfectly good and working) programs to get around it.