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?) ## ## ## #### ## ####