[comp.sys.amiga] Amiga Serial Device Hangups

carroll@unirot.UUCP (mark carroll) (12/08/86)

  Im currently working on a Bulletin Board system for the amiga, using CSIs
multi-forth. ( Which is a FANTASTIC product). My problem is 
  A> How can I detect when my modem loses a carrier? The SerErr Carrier
    lost NEVER occurs unless I unplug my modem from the computer.
  B> How can I drop the line without using the AT command? I know I can
    shut off the DTR by closing the serial device. But when I do it this was,
    when I try to reopen the serial.device for the next user, the system
    crashes.  Can I shut off DTR without closing the device? And does
    anyone have any suggestions on why reopening the serial device crashes
    the system? This also happens if I exect DBWs vt100, and run my system.

           Thanks in advance for your assistance,
                  Mark Carroll
           ARPA: CARROLL@Aim.rutgers.edu
           uucp: !rutgers!unirot!carroll

lyles@tybalt.caltech.edu (Lyle N. Scheer) (12/08/86)

In article <197@unirot.UUCP> carroll@unirot.UUCP (mark carroll) writes:
>
>  Im currently working on a Bulletin Board system for the amiga, using CSIs
>multi-forth. ( Which is a FANTASTIC product). My problem is 
>  A> How can I detect when my modem loses a carrier? The SerErr Carrier
>    lost NEVER occurs unless I unplug my modem from the computer.

That sounds like a modem problem, not an Amiga problem.  It sounds like your
modem constantly sends the carrier detect signal.  In fact, it sounds as if
you have a Volksmodem 12, which does that.  If so, there are some dip-switches
in back, one of will will set it so CDC is always set, or works normally.  If
you have some other modem, I'd look in the manual for such a switch/software
toggle.
IF the above is not the solution, you can do a cludge and constantly look for
the input of NO CARRIER.  It works, but is inelegant.

>  B> How can I drop the line without using the AT command? I know I can
>    shut off the DTR by closing the serial device. But when I do it this was,
>    when I try to reopen the serial.device for the next user, the system
>    crashes.  Can I shut off DTR without closing the device? And does
>    anyone have any suggestions on why reopening the serial device crashes
>    the system? This also happens if I exect DBWs vt100, and run my system.

Again, dropping the modem with DTR is dependant on the modem.  Personally,
I would use the +++ and ATH0, since some modems will not allow DTR, and if
you want to distribute this program, people will have these modems.  Your
crashes are probably an element of not closing something.


  My base of knowledge comes from about four years of BBS programming.  I've
done two so far on the Amiga, one in Basic, and one in Modula-2(I'm still
working on it), and before that, one on the Apple ][+ with elements of basic
and 6502.  I currently have a Volksmodem 12, and try to have a BBS up as much
as possible.  I will be happy to answer whatever modem/serial programming
questions I am able to.

>
>           Thanks in advance for your assistance,
>                  Mark Carroll
>           ARPA: CARROLL@Aim.rutgers.edu
>           uucp: !rutgers!unirot!carroll


					Wonko the Sane
				      (you call this SANE??)

Disclaimer: I am totally irresponsible.  So shoot me then.

chiu@princeton.UUCP (Kenneth Chiu) (12/09/86)

In article <197@unirot.UUCP> carroll@unirot.UUCP (mark carroll) writes:
>  A> How can I detect when my modem loses a carrier? The SerErr Carrier
>    lost NEVER occurs unless I unplug my modem from the computer.
Did you try SDCMD_QUERY?  From the manual description, it seems like it would
it work, but I have not used it for that purpose.

>    crashes.  Can I shut off DTR without closing the device? And does
>    anyone have any suggestions on why reopening the serial device crashes
>    the system? This also happens if I exect DBWs vt100, and run my system.
I have had some problem with crashes while exiting.  I think you have to be
very careful about cleaning up, especially with the timer device.  Make sure
all requests have been aborted and put back, and make sure you close the device
before deallocating ports, requests, etc.
-- 
Kenneth Chiu                                              UUCP: princeton!chiu
Princeton University Computer Science Department        BITNET: 6031801@PUCC