[comp.sys.atari.8bit] Serial Communication

gil@limbic.UUCP (Gil Kloepfer Jr.) (11/30/88)

In article <Nov.28.21.41.10.1988.12161@topaz.rutgers.edu> wilmott@topaz.rutgers.edu (Ray Wilmott) writes:
|>how can I *read* data coming over the modem.

You are reading properly.  You can use GET or INPUT to get data from a
port opened in concurrent I/O mode (this is what the XIO 40 and the mode
13 in the OPEN statement do).

|>OPEN #3,13,0,"R:"
|>XIO 40,#3,0,0,"R:"
|>PRINT #3; "Here's my Data!"

This looks fine.

However, saying you saw the modem lights blink doesn't necessarily mean you
sent the data out the proper way.  The baud rate needs to be set for the
port, as well as stop bits, etc.  This is a group of XIO's that you can get
from "Your Atari Computer" (good book, BTW) or from the 850 interface manual.

|>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.

You might be getting something back, but if the interface is at the wrong
baud rate, you'll get garbage.  Check this out.

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.

Getting serial I/O to work on the Atari is almost like an art -- there's
lots of restrictions and options to deal with -- getting them all to work
the right way requires patience, and a locally connected terminal handy.
I hope this gets you (and others) started, but it's not nearly enough to
solve the problem.

-------
Gil Kloepfer, Jr.          U-Net: {decuac,boulder,talcott,sbcs}!icus!limbic!gil
ICUS Software Systems      Voice: (516) 968-6860 [H]   (516) 746-2350 x219 [W]
P.O. Box 1                 Internet:  gil@icus.islp.ny.us
Islip Terrace, NY  11752   "Life's a ...  well, you know..."

rjung@sal43.usc.edu (Robert allen Jung) (12/02/88)

In article <406@limbic.UUCP> gil@limbic.UUCP (Gil Kloepfer Jr.) writes:
>In article <Nov.28.21.41.10.1988.12161@topaz.rutgers.edu> 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?)                  ## ## ##
                                                         ####  ##  ####