jimbo@well.UUCP (Jim Bolton) (01/28/89)
I would like a bit of help concerning the Amiga's RS-232 port and serial device. I hope someone can help answer my question. I've almost completed a bbs/conference application and early today was looking at the way I handle DTR. Currently to drop DTR I close the serial device, wait 1 second, and then reopen the serial device. This procedure covers almost all modems, but does seem a bit awkward from what I've done on other systems. What I would like to do is inhibit DTR for n/10 seconds and if this doesn't force hang-up then an online escape command could be issued to force the modem to command mode where an explicit hang-up command could be issued. This seems like a much better way to handle it. So, I would like to know if it is possible to inhibit DTR on the Amiga's RS-232 serial port and if so could you point me in the right direction. Thanks in advance for any help! ------------------------------------------------------------------------- - CUTE SOFTWARE Jim Bolton P.O. Box 1496 Zephyr Cove, NV 89448 - - (702) 588-7179 Call the CUTE BBS at (714) 532-5698 - -------------------------------------------------------------------------
papa@pollux.usc.edu (Marco Papa) (01/29/89)
In article <10511@well.UUCP> jimbo@well.UUCP (Jim Bolton) writes: >I would like a bit of help concerning the Amiga's RS-232 port and serial >device. I hope someone can help answer my question. >I've almost completed a bbs/conference application and early today was >looking at the way I handle DTR. Currently to drop DTR I close the serial >device, wait 1 second, and then reopen the serial device. .... >So, I would like to know if it is possible to inhibit DTR on the Amiga's >RS-232 serial port and if so could you point me in the right direction. This is some code that might be helpful to you. [Gee, I come back after a week at the MIT X Conference and I am back 350 messages, gulp!]. /* * dtr.c -- handle DTR */ #include <exec/types.h> #include <hardware/cia.h> /*********************************/ /* set com DTR line */ /* false = DTR off; DTR = dtr on */ /*********************************/ static struct CIA *Ciab; /* this breaks the 1.2 cia.h include */ SetDTR(set) int set; { Ciab = (struct CIA *) 0xBFD000; Forbid(); Ciab->ciaddra |= CIAF_COMDTR; /* set DTR as output */ if (set) Ciab->ciapra &= ~CIAF_COMDTR; /* set DTR low */ else Ciab->ciapra |= CIAF_COMDTR; /* set DTR high */ Permit(); } DropDTR() { SetDTR(FALSE); /* drop DTR */ Delay(2L); /* wait 40 msec. */ SetDTR(TRUE); /* set DTR */ } Enjoy. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
perry@madnix.UUCP (Perry Kivolowitz) (01/31/89)
Marco's suggestion to access the CIA registers directly for toggling
DTR is *not* a good idea for the following reason: No other serial
port besides the internal one uses the CIA.
In other words, in this as in all things, going to the hardware
directly will bind you into some pretty severe limitations. In this
case manipulating DTR in the suggested manner is a sure file way to
never be able to use expansion serial ports.
Another suggestion:
(Bryce are you listening? :-)
In an earlier incantation of my serial device driver I added a command
which would allow access to all setable outputs. Something like:
io_Command = CMD_SET_SERIAL_CTRL_LINES;
io_Length = MASK_OF_BITS_TO_BE_AFFECTED;
io_Actual = WHAT_TO_SET_THEM_TO;
DoIO(IOB)
If we all agree to make this a standard, well then, it will become a
standard.
Note: My current serial device driver (the one that deals quite nicely
with 115KB :-) does not have this feature anymore but I might add it
back in if there's any requests.
--
Perry Kivolowitz, ASDG Inc.
ARPA: madnix!perry@cs.wisc.edu {uunet|ncoast}!marque!
UUCP: {harvard|rutgers|ucbvax}!uwvax!astroatc!nicmad!madnix!perrypapa@pollux.usc.edu (Marco Papa) (02/01/89)
In article <443@madnix.UUCP> perry@madnix.UUCP (Perry Kivolowitz) writes: |Marco's suggestion to access the CIA registers directly for toggling |DTR is *not* a good idea for the following reason: No other serial |port besides the internal one uses the CIA. ... |Another suggestion: |In an earlier incantation of my serial device driver I added a command |which would allow access to all setable outputs. Something like: | |io_Command = CMD_SET_SERIAL_CTRL_LINES; |io_Length = MASK_OF_BITS_TO_BE_AFFECTED; |io_Actual = WHAT_TO_SET_THEM_TO; | |DoIO(IOB) | |If we all agree to make this a standard, well then, it will become a |standard. Perry, I just received word from Bryce that the "standard" way to drop DTR is to close and then reopen the device. This should work no matter what serial device and unit one is using. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
elg@killer.DALLAS.TX.US (Eric Green) (02/01/89)
in article <15000@oberon.USC.EDU>, papa@pollux.usc.edu (Marco Papa) says: > In article <10511@well.UUCP> jimbo@well.UUCP (Jim Bolton) writes: >>looking at the way I handle DTR. Currently to drop DTR I close the serial >>device, wait 1 second, and then reopen the serial device. > .... >>So, I would like to know if it is possible to inhibit DTR on the Amiga's >>RS-232 serial port and if so could you point me in the right direction. > > This is some code that might be helpful to you. [Gee, I come back after a week > at the MIT X Conference and I am back 350 messages, gulp!]. [... some C code to hack directly at the CIA to turn off the DTR bit] Note that hacking straight at the CIA will *BREAK* if you are using a multiserial card and accessing any serial device other than unit 0. Now that we are FINALLY getting multi-serial cards, PLEASE don't do something brain-damaged like this! If you want your program to work with a multiserial card, do the hardware-DTR hack only for unit 0. And even then it may be inappropriate. E.g., I was looking at what would be involved to get current programs to run in a multiserial environment, and came up with the idea of sending a command to the new serial.device telling it, "OK, the next thing coming in will say that it's unit 0, but actually open it as unit 5." Your current scheme, closing the serial.device, probably will break the least when used in a multiserial environment. -- | // Eric Lee Green P.O. Box 92191, Lafayette, LA 70509 | | // ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg (318)989-9849 | | \X/ >> In Hell you need 4Mb to Multitask << |
papa@pollux.usc.edu (Marco Papa) (02/01/89)
In article <6992@killer.DALLAS.TX.US> elg@killer.DALLAS.TX.US (Eric Green) writes: |in article <15000@oberon.USC.EDU|, papa@pollux.usc.edu (Marco Papa) says: || In article <10511@well.UUCP| jimbo@well.UUCP (Jim Bolton) writes: |||looking at the way I handle DTR. Currently to drop DTR I close the serial |||device, wait 1 second, and then reopen the serial device. || .... |||So, I would like to know if it is possible to inhibit DTR on the Amiga's ^^^^^^^^^^^^^^^^^^^^^^^^ |||RS-232 serial port and if so could you point me in the right direction. ^^^^^^^^^^^^^^^^^^ || || This is some code that might be helpful to you. |[... some C code to hack directly at the CIA to turn off the DTR bit] | |Note that hacking straight at the CIA will *BREAK* if you are using a |multiserial card and accessing any serial device other than unit 0. ^^^^^^^^^^^^^^^^ |Now that we are FINALLY getting multi-serial cards, PLEASE don't do |something brain-damaged like this! Read the original question, dude. He said "Amiga RS-232 serial port", NOT a multi-serial device. |Your current scheme, closing the serial.device, probably will break |the least when used in a multiserial environment. As Bryce posted, closing/wait/opening the "current" (multi)serial device is the only way to drop DTR in a compatible way, and all multi-serial hardware manufacturers should support it. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
peter@sugar.uu.net (Peter da Silva) (02/01/89)
In article <6992@killer.DALLAS.TX.US>, elg@killer.DALLAS.TX.US (Eric Green) writes: > Note that hacking straight at the CIA will *BREAK* if you are using a > multiserial card and accessing any serial device other than unit 0. It will also break if you're accessing unit 0 on the multiserial card. serial.device, unit 0, is the internal Amiga port. newserial.device, unit 0, should be the new serial device's first port. Please, folks, don't try to hide your drivers in a new "serial.device". Use a new device name. People are going to have to adapt their programs to this environment anyway, so you might as well specify a new device name. Besides, it's easier for q. random hacker to patch a name in FooTalk than disassembling it to find out how they set up the open call. A new device name is better for the well behaved and the kludgemeisters alike. -- Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. ...texbell!sugar!peter, or peter@sugar.uu.net 'U`
perry@madnix.UUCP (Perry Kivolowitz) (02/02/89)
That'd be fine by me Marco, but maybe Bryce isn't aware of the existence
of some weird pieces of equipment out there which uses DTR as a control
line which must be diddled while other things are happened on the serial
port.
One kind of laser disk controller comes to mind....
Bryce....that approach (DTR is managed by the open/close state of the
serial device) is completely fine for the general case...but...we should
have the (standard) ability to diddle the control lines for the patholo-
gical case of some particular types of hardware.
What do you say?
Perry
--
Perry Kivolowitz, ASDG Inc.
ARPA: madnix!perry@cs.wisc.edu {uunet|ncoast}!marque!
UUCP: {harvard|rutgers|ucbvax}!uwvax!astroatc!nicmad!madnix!perrypapa@pollux.usc.edu (Marco Papa) (02/03/89)
In article <460@madnix.UUCP> perry@madnix.UUCP (Perry Kivolowitz) writes: >That'd be fine by me Marco, but maybe Bryce isn't aware of the existence >of some weird pieces of equipment out there which uses DTR as a control >line which must be diddled while other things are happened on the serial >port. > >One kind of laser disk controller comes to mind.... You're right. DTR handling with close/open is fine for hangup of modems, but not for all possible serial devices and uses of it. A way to control individual lines of the serial port (with Perry's way or any equivalent one, see later) should be included in a new version of the serial device spec. This should be made standard ASAP so that all new multiserial devices that are now coming to market do it in a compatible way (to make life easier for us software writers, thank you :-). One way I like could be to make the opposite of the SDCMD_QUERY command (call it SDCMD_SET, for example) that can set/clear bits in the same order as the ones returned in io_Status by SDCMD_QUERY. This would be easy to use by a software writer, since all it is needed to set/reset a line would be: 1. SDCMD_QUERY 2. or/and io_Status with a mask 3. SDCMD_SET Any thoughts (Perry, Bryce, Aaron) ? -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
bryce@cbmvax.UUCP (Bryce Nesbitt) (02/04/89)
In article <460@madnix.UUCP> perry@madnix.UUCP (Perry Kivolowitz) writes: >...but maybe Bryce isn't aware of the existence >of some weird pieces of equipment out there which uses DTR as a control >line... I certainly am aware. But if you want a single method you can use NOW (with the serial.device on V1.2 and V1.3 Workbench disks) Close/Re-Open is what you want to use. The person asking the question wanted to hang up a modem. In the future, there will be an opposite to CMD_QUERY available, but only on the newer generation. Programs will be able to define any of the control lines that the hardware device supports (and get a mask of just what lines those are). -- |\_/| . ACK!, NAK!, EOT!, SOH! {O o} . Bryce Nesbitt (") BIX: bnesbitt U USENET: cbmvax!bryce@uunet.uu.NET -or- rutgers!cbmvax!bryce Disclaimer: I'm not an official, and this is not an official opinion.
cg@myrias.UUCP (Chris Gray) (02/10/89)
In article <5882@cbmvax.UUCP> bryce@cbmvax.UUCP (Bryce Nesbitt) writes: In replying to a question on how to lower DTR, Bryce writes: >Close the device, then reopen it. (include error checking!) >This will drop then raise DTR. >Eventually there will be a better way... but this one works for all versions >of the serial.device back to V1.0!! >It will also work for extended units. I first tried this for Amiga Empire on my A1000. The light on my modem did NOT go off. I had to go directly to the hardware and toggle the bit - that DID work. The problem went away when I got an A2000. On other machines, the open/close combo did work. I don't at all understand how this was happening, but it was quite repeatable. Also, a friend's A1000 has the same problem. -- Chris Gray Myrias Research, Edmonton +1 403 428 1616 {uunet!mnetor,ubc-vision,watmath,vax135}!alberta!myrias!cg
papa@pollux.usc.edu (Marco Papa) (02/11/89)
In article <852@myrias.UUCP> cg@myrias.UUCP (Chris Gray) writes: |In article <5882@cbmvax.UUCP| bryce@cbmvax.UUCP (Bryce Nesbitt) writes: ||Close the device, then reopen it. (include error checking!) ||This will drop then raise DTR. ||Eventually there will be a better way... but this one works for all versions ||of the serial.device back to V1.0!! ||It will also work for extended units. | |I first tried this for Amiga Empire on my A1000. The light on my modem did |NOT go off. I had to go directly to the hardware and toggle the bit - that |DID work. The problem went away when I got an A2000. On other machines, the |open/close combo did work. I don't at all understand how this was happening, |but it was quite repeatable. Also, a friend's A1000 has the same problem. Try this: CloseDevice(...); Delay(50L); /* wait 1 sec. */ OpenDevice(...); -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
mcr@julie.UUCP (Michael Richardson) (02/12/89)
Marco Papa Doc writes: >As Bryce suggested, a "better" way is to close the device, wait 1 sec and >then reopen it (with the SAME parameters). I tried it and it works just >fine. DTR is dropped properly. Do I have to close ALL my serial.devices or just one? (In the case of SERF_SHARED, and opening it once for read and once for write.) I built my own serial cable, and I don't have DTR wired up, but I'll get around to doing it sometime. One advantage (not from a security point of view) is that I'll sometimes crash the machine in another window, but when I reboot I'm still connected to the SUN. Can we have a 'hangupOnClose' flag then? And a standard way to drop DTR? (What if I use it to dial a dumb modem? Or to indicate that the next bytes are commands for the modem, or 'out of band' data in a network?) >Multi-serial manufacturers should ensure that this technique works on their >hardware too. I'd rather they set a (defacto) standard than conform here. How about it Perry? Does the sioxbs.device (or whatever) provide this? >-- Marco Papa 'Doc' -- :!mcr!: Michael Richardson Amiga v--------+ UUCP: uunet!attcan!lsuc!nrcaer!julie!mcr | INTERNET mcr@doe.carleton.ca Fido: Michael Richardson @ 1:163/109.10<--+ Alter @ 7:483/109.10
perry@madnix.UUCP (Perry Kivolowitz) (02/19/89)
In article <0352.AA0352@julie> mcr@julie.UUCP (Michael Richardson) writes: > I'd rather they set a (defacto) standard than conform here. How about > Perry [does ASDG's device driver drop DTR?] Yes, The siosbx.device driver is written to drop dtr on full device close. Full device close meaning when the open count on the port drops to zero. -- Perry Kivolowitz, ASDG Inc. ARPA: madnix!perry@cs.wisc.edu {uunet|ncoast}!marque! UUCP: {harvard|rutgers|ucbvax}!uwvax!astroatc!nicmad!madnix!perry CIS: 76004,1765 (what was that about ``giggling teenagers''?)
jdow@gryphon.COM (J. Dow) (03/04/89)
In article <15068@oberon.USC.EDU> papa@pollux.usc.edu (Marco Papa) writes: >In article <443@madnix.UUCP> perry@madnix.UUCP (Perry Kivolowitz) writes: >|Marco's suggestion to access the CIA registers directly for toggling >|DTR is *not* a good idea for the following reason: No other serial >|port besides the internal one uses the CIA. >... >|Another suggestion: >|In an earlier incantation of my serial device driver I added a command >|which would allow access to all setable outputs. Something like: >| >|io_Command = CMD_SET_SERIAL_CTRL_LINES; >|io_Length = MASK_OF_BITS_TO_BE_AFFECTED; >|io_Actual = WHAT_TO_SET_THEM_TO; >| >|DoIO(IOB) >| >|If we all agree to make this a standard, well then, it will become a >|standard. > >Perry, > >I just received word from Bryce that the "standard" way to drop DTR >is to close and then reopen the device. This should work no matter >what serial device and unit one is using. > >-- Marco Papa 'Doc' This is a badly broken approach. There MUST be a method of dropping DTR in a multitasking environment without losing the serial device. If you close the device something else can sneak in there and steal it. I hope Bryce rethinks this serial attitude problem and cleans this freking thing up a bit. All the bits of the port should be controllable by the application software through standard means. Otherwise some uses becoem too awkward to bear thinking about. {`_'} Grump -- Sometimes a bird in the hand leaves a sticky deposit. Perhaps it were best it remain there in the bush with the other one. {@_@} jdow@bix (where else?) Sometimes the dragon wins. Sometimes jdow@gryphon.CTS.COM the knight. Does the fair maiden ever {backbone}!gryphon!jdow win? Surely both the knight and dragon stink. Maybe the maiden should suicide? Better yet - she should get an Amiga and quit playing with dragons and knights.
limonce@pilot.njin.net (Tom Limoncelli) (03/05/89)
In article <12897@gryphon.COM> jdow@gryphon.COM (J. Dow) writes: > -- > Sometimes a bird in the hand leaves a sticky deposit. > Perhaps it were best it remain there in the bush with the other one. > > {@_@} > jdow@bix (where else?) Sometimes the dragon wins. Sometimes > jdow@gryphon.CTS.COM the knight. Does the fair maiden ever > {backbone}!gryphon!jdow win? Surely both the knight and dragon > stink. Maybe the maiden should suicide? > Better yet - she should get an Amiga and > quit playing with dragons and knights. Ok, J Dow, your signature really, really puzzles me every time I read a post of yours. It must be great to have such a hinting signature. Now I beg you to tell me what it means. Please stop the tease! \ /\ Tom -- Tom Limoncelli -- tlimonce@drunivac.Bitnet -- limonce@pilot.njin.net Drew University -- Madison, NJ -- 201-408-5389 Standard Disclaim er.
jesup@cbmvax.UUCP (Randell Jesup) (03/07/89)
In article <12897@gryphon.COM> jdow@gryphon.COM (J. Dow) writes: >>I just received word from Bryce that the "standard" way to drop DTR >>is to close and then reopen the device. This should work no matter >>what serial device and unit one is using. >> >>-- Marco Papa 'Doc' > >This is a badly broken approach. There MUST be a method of dropping DTR in >a multitasking environment without losing the serial device. If you close the >device something else can sneak in there and steal it. I hope Bryce rethinks >this serial attitude problem and cleans this freking thing up a bit. All the >bits of the port should be controllable by the application software through >standard means. Otherwise some uses becoem too awkward to bear thinking about. >{`_'} Grump Don't be grumpy, Joanne. This is the approved way to drop DTR _until_ 1.4 comes out. That will have a far better way to handle it. (Plus we guarantee that close/open will drop dtr in 1.4, so current code will be ok.) -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup