jimmy@denwa.UUCP (Jim Gottlieb) (08/21/88)
Recently, someone suggested that by doing a 'mknod ttyd0 c 0 128' you would create a descriptor for the same line as tty000, except that it would not be necessary to hold CD high to communicate with the port. Was anyone able to get this to work? I did this, but found that my new port also needed CD high to connect to it. If not, it may be time to get out the soldering iron and tie the TrailBlazer's DSR to the 3B1's CD. -- Jim <jimmy@denwa.uucp> or <jimmy@pic.ucla.edu>
jbm@uncle.UUCP (John B. Milton) (08/25/88)
In article <168@denwa.UUCP> jimmy@denwa.UUCP (Jim Gottlieb) writes: >Recently, someone suggested that by doing a 'mknod ttyd0 c 0 128' you >would create a descriptor for the same line as tty000, except that it >would not be necessary to hold CD high to communicate with the port. > >Was anyone able to get this to work? I did this, but found that my new >port also needed CD high to connect to it. > >If not, it may be time to get out the soldering iron and tie the >TrailBlazer's DSR to the 3B1's CD. >-- >Jim <jimmy@denwa.uucp> or <jimmy@pic.ucla.edu> It works fine for me (UNIX 3.51). If you have a Trailblazer, you should never need weird cables, just change register 54. If you have HDB, there are a lot more fun things you can do in the Devices and Dialers files as far as outgoing connections go (Mm). I think it is time to post my modified version of the program modem-ctl that was posted to the net a while back. I am using a TB to connect bi-directionally at any (300, 1200, 2400, PEP) speed. The modem-ctl program runs from inittab BEFORE the getty. It talks to the modem to make it happy, then sits there wait- ing for "RING" to come in. It then read the CONNECT xxxx string. It uses this xxxx speed string to fork off a getty at the RIGHT speed. This way incomming calls connect at the right speed and do NOT NEED FLOW CONTROL. The other advantage is that any program doing a TCGETA will get the right speed and know how to behave. While this program is waiting for ring, or while it is starting up, it keeps checks for a lock file between each character it read from the modem. If it notices that the lock file has appeared, it gets off the line to let whatever is about to go out have the line. I am using a 10 wire, straight through cable, HDB UUCP and these registers: E0 F1 M1 Q0 T V1 X1 Version BA4.00 S00=000 S01=000 S02=035 S03=013 S04=010 S05=008 S06=002 S07=060 S08=002 S09=006 S10=007 S11=070 S12=050 S45=255 S47=004 S48=000 S49=000 S50=000 S51=254 S52=002 S53=004 S54=003 S55=000 S56=017 S57=019 S58=002 S59=000 S60=003 S61=045 S62=003 S63=001 S64=000 S65=000 S66=000 S67=000 S68=255 S90=000 S91=000 S92=001 S95=000 S100=000 S101=000 S102=000 S104=000 S110=001 S111=030 S112=001 S121=000 When modem-ctl starts talking to the modem, it sends ATM1X1Q0 so the messages will be what the send-expect stuff wants. Note that S66=0. On outgoing calls I set it to ATS66=1. Note also that R0=0. Once the program gets the "RING" from the modem, it sends "ATA" to tell the modem to pick up the phone. This way, if my system is totally crashed, it won't put out the "ATA", so it won't answer the phone, so I can checked for system !crashed from any phone. The historical status of my machine will also be reflected in the systems that call mine regularly. I also have my wake up character different from + (S2), so that when I am connected to another Hayes, only one of us enters command mode. This program is running on uncle and n8emr. These two machines are UNIXpcs with 'blazers and HDB UUCP. It is also running on strlna which is a Sperry 5000/90 with two modems: a Prometheus doing 2400 and 1200 and a Fastalk (motorola Hayes clone). It is running vanilla UUCP with very little outgoing activity. On the Sperry, the reliability of both of the dialups has increased dramaticaly. The Prometheus in particular used to hang the port for various reasons. Even now, the modem-ctl program has to beat on it several times every now and then to get it to work. Grunging around in this program has taught me a lot about termio(7). As usual there are a lot of details there in the manual that just don't sink in until about the 100th time. By then you have the rest of the man page memorized. The one that got me was the implications of the process group in relation to controlling tty (setpgrp(2) et. al.) I am still having one problem I can not seem to work out though. While the modem-ctl program is blocked in a read waiting for RING, it does NOT get the first character to come back from the modem. If I cu out and do ATN?, the tty driver seems to let a bunch of characters go to cu instead of the read that is blocked. This goes on until what seems like about 10-20 characters, at least it is relatively consistant. Yes, I am using hardware flow control on both ends. There is some funny business going on related to O_NDELAY and CLOCAL. Supposedly by this time O_NDELAY has been disabled with fcntl() since CLOCAL has been set. What does UNIX do when there is more than one process blocked for the same operation on the same device? Does it guarantee FCFS (first come first served)? "Ok, where can I get this program..." I will post to unix-pc.sources for beta and later to comp.sources.unix So you can find it, I have renamed it to "prtty", which stands for pre-tty. I was going to call it "pretty", but there is already a program in the archives by that name. John -- John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu home: (614) 294-4823, work: (614) 459-7641; CP/M to MP/M, MS-DOS to OS/2
rhealey@umn-d-ub.D.UMN.EDU (Rob Healey) (09/03/88)
In article <168@denwa.UUCP> jimmy@denwa.UUCP (Jim Gottlieb) writes: >Recently, someone suggested that by doing a 'mknod ttyd0 c 0 128' you >would create a descriptor for the same line as tty000, except that it >would not be necessary to hold CD high to communicate with the port. I can not tell a lie, I said this. I'm running 3.5, maybe that makes a difference? I'm pretty sure it ignored CD because a request on tty000 would block but ttyd0 didn't. Maybe it was something that made it look like ttyd0 was ignoring the CD line. On some BSD systems setting the high bit of the minor device number means a non-blocking open on the line is possible. Since the OS does have a few BSD 4.1 quirks I thought the assumption on ttyd0 was reasonable. -Rob