Path: utzoo!utgpu!watmath!clyde!att!pacbell!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!oberon!nunki.usc.edu!sal43.usc.edu!rjung
From: rjung@sal43.usc.edu (Robert  allen Jung)
Newsgroups: comp.sys.atari.8bit
Subject: Re: Serial Communication (was: HELP!)
Keywords: modem - how do it work?
Message-ID: <2057@nunki.usc.edu>
Date: 1 Dec 88 16:04:05 GMT
References:  <406@limbic.UUCP>
Sender: news@nunki.usc.edu
Reply-To: rjung@sal43.usc.edu (Robert  allen Jung)
Organization: University of Southern California, Los Angeles, CA
Lines: 51

In article <406@limbic.UUCP> gil@limbic.UUCP (Gil Kloepfer Jr.) writes:
>In article  wilmott@topaz.rutgers.edu (Ray Wilmott) writes:
>|>Okay all you Atari guru's...how do I READ data now.  "INPUT #3,A$"
>|>doesn't do anything (I can see by the modem lights that data is
>|>being sent, but the string always ends up empty). "GET #3, A" results
>|>in either nothing, or the letter "Q" (ascii #81) no matter what data
>|>was being sent.
>
>Next thing you will ask (as I did) is how to check if there are characters
>waiting in the input buffer to be read.  This is so you can go off and
>do something else until characters are ready to be processed.  The following
>code will check this:
>
>	STATUS#3,X
>	A=PEEK(747)+256*PEEK(748)
>
>A will contain the number of characters in the receive buffer, or zero if
>none have been received yet.  The STATUS command is important.  This is in
>my 850 manual page 29.

  Okay, a related question: I'm trying to print out a large string through
the modem, while scanning for any keys that the reciever might send in during
the process (sort of like a "hot keys" feature on some BBS's). I use the
following code:

  10 READ A$:IF A$="***" THEN RETURN
  20 ? #3; A$
  30 STATUS #3,X:IF PEEK(747) THEN GET #3,X:RETURN
  40 GOTO 10

  Now, by your explainations (and all the documentation I've seen), this should
work fine -- When someone presses a key, the information will stop after the
last string, and X will contain the ATASCII value of the key pressed.

  Problem is, when the reciever presses a key, it gets "buffered". If you
whack a key when the first line is displayed, the character won't get
processed until several lines further down. Also, the slower the baud rate,
the worse the situation gets -- 300 baud is almost non-responsive, 1200 baud
requires a few seconds, and 2400 baud is acceptable.

  What am I doing wrong, and how do I fix it?

						--R.J.
						B-)

 -----------------------------------------------------------------------------
  Disclaimer: These are my views, and mine alone.
                                                             # ## #
  Mailing address: Beats me, just reply to this message      # ## #
                    (rjung@nunki.usc.edu?)                  ## ## ##
                                                         ####  ##  ####