freetz Posted August 8, 2019 Share Posted August 8, 2019 Hi everyone, I was wondering if there is some kind of timeout mechanism when using INPUT with an external device in BASIC? The problem I'm facing is that INPUT seems to wait for something like an EOL/CR/LF to return control to the program. In my scenario, where I receive data from a serial interface using the R: handler, there may not be an end-of-line character for a long time if the other side does not type anything. If that is the case for let's say longer than 10 seconds, I want my program to continue processing. So is there a way to prevent waiting - at worst - forever? In the beginning, I tried using GET #1,A, but that was quite a lot slower than INPUT. Plus, I also forgot the memory address that tells me how may bytes are waiting in the IOCB buffer and couldn't find the information after quite some searching. Could anyone give me a pointer? And maybe tell me why GET is so much slower than INPUT and if there is a possibility to speed GET up? Thanks a lot in advance, F. Quote Link to comment Share on other sites More sharing options...
freetz Posted August 8, 2019 Author Share Posted August 8, 2019 Ok, part of the answer to my problem can be found on page 8/9 of the technical manual of the Atari 850: BREAK key is disabled for concurrent mode I/O, and it states that there is no way to make INPUT end after a timeout. GET in combination with STATUS is then recommended and the memory location I was looking for is 747. The question remains if there are ways (accessible to BASIC) to speed things up with GET? Quote Link to comment Share on other sites More sharing options...
Rybags Posted August 8, 2019 Share Posted August 8, 2019 For devices other than K: E: and S: using INPUT and even the record oriented XIO commands in Basic can give undesired results. Often the incoming data isn't record oriented with the CR character which will be problematic with Basic handling. You're probably way better off using an assembly routine called by USR which passes IOCB, command and buffer address & length. Quote Link to comment Share on other sites More sharing options...
freetz Posted August 8, 2019 Author Share Posted August 8, 2019 Thanks! I assumed that this would be necessary but had hoped that this could be prevented as I'm writing an example for more basic users. But I'll then probably provide the routine as part of the BASIC program... Quote Link to comment Share on other sites More sharing options...
Rybags Posted August 8, 2019 Share Posted August 8, 2019 Re GET - yep, it's painfully slow. Insufficient to be able to handle short IRG input from cassette, given that 600 bps equates to about a byte every NTSC frame that's an indicator of what to expect. Quote Link to comment Share on other sites More sharing options...
thorfdbg Posted August 8, 2019 Share Posted August 8, 2019 There is no way to timeout INPUT. What you can do is to query KeyCodeShadow, and if this is 255, continue operation of the program. If it is set, get the next keypress through GET. You would then need to implement some elementary editing functions (such as backspace) yourself. For the serial port, you can find out how much data has been buffered up and can be retrieved. For that, issue a status, and then read the number of buffered bytes from $2eb and $2ec. If this is zero, there is nothing to read from R: Otherwise, you can retrieve the bytes without blocking. This should give you about an idea how to run the input loop. Quote Link to comment Share on other sites More sharing options...
freetz Posted August 8, 2019 Author Share Posted August 8, 2019 Great, thanks! I'll try that out... Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.