Atari BASIC Call "STATUS" for RS232

[rickcollette]

My specific use case (however, looking at this spec from the 850 manual, I can see where there would be other cases):

Check for data in an outgoing buffer.

Atari BASIC example:

10 OPEN #1,13,0,"R:" : OPEN R: DEVICE IN CONCURRENT MODE FOR R/W 20 STATUS #1,X:IF PEEK(749)>0 THEN GOSUB 50 30 ? "Buffer Empty!" 40 GOTO 20 50 ?"Buffer still has data..." 60 RETURN

STATUS command The STATUS command is useful for determining many facts about an RS232-C port and the state of the Interface Module. You can check for certain specific error conditions, to find out why certain errors have occurred, to check parity, and so on. The STATUS command allows you to determine the amount of data in the input and output buffers while concurrent mode I/O is in effecr STATUS also allows you to check the state of the RS-232-C control lines DSN CTS, CRX (and the state of RCV at the time you issue the STATUS command). The STATUS command may be issued only through a channel opened to an RS-232-C port. You may issue the command whether or not concurrent mode I/O is in effect. If this mode is in effect to a port, you cannot obtain status information (via the STATUS command) from another port. The information returned by a STATUS command is different according to whether or not concurrent mode I/O is in effecr When concurrent mode I/O is in effect, the STATUS command allows you to see how full your input and output buffers are, but you cannot check on the state of the control lines DTN CTS, CRX and RCV. (RCV can be directly checked, howeven by PEEKing at the computer's serial I/O control register). When concurrent mode I/O is not in effect, you get no information about buffers, of course, but the state of the control lines can be checked. There are other minor differences in the effect of the STATUS command in the two cases. In BASIC, the STATUS REQUEST command is implemented as a "compound" command--that is, you must code multiple BASIC statements to get the status. The first, of course, is the STATUS command. This is followed by uses of the PEEK function to retrieve status which is left in a small status area by the STATUS command. The STATUS command looks like this in BASIC: STATUS #channel, avar Here, #channel specifies the channel (1-7) through which you have OPENed the RS-232-C port. You may issue this statement to the port before andlor after concurrent mode I/O is started. Avar is a variable which will get the status OF THE STATUS STATEMENT ITSELF. That is, avar will be set to the input/output system's onebyte status that is returned when BASIC calls the I/O system - since the I/O system call here is the STATUS, the value returned is the I/O system`s determination about how the STATUS command wenr This number is the same kind of number returned to BASIC by the I/O system after ANY I/O call, but in the other BASIC I/O statements, BASIC looks at the number itself to see if the I/O was completed without error. The STATUS command simply puts the number in the avar. 25 This status number can be interpreted just like one of the ERROR codes - for example, you will get 130 if you neglected to OPEN the channel, since an unopen IOCB does not specify any peripheral device and error 130 means "Nonexistent Device Specified". The status number will be 1 if the STATUS call was completed without error. The status number will be some error number greater than 127 if there was some problem with the STATUS call. If the STATUS call is successful, up to four bytes of information are stored in locations 746, 747, 748 and 749. Location 746 always contains error status bits relating to the status history of the RS232-C port. The other three locations will contain buffer use information if concurrent mode I/O is active. If concurrent mode I/O is not active, 747 contains status bits relating to DSN CTS, CRX, and RCV on the RS-232-C port and locations 748 and 749 hold nothing. Table 1 of APPENDIX 4 shows the definition of the error bits in location 747. The table gives each bit a decimal value which shows how that bit, if "on" or 1 ,as opposed to "off" or 0), adds to the total value of the byte when interpreted as a decimal number. The meaning of each of these error bits are discussed in APPENDIX 4, but first here is a BASIC example showing how you can check one of the bits: 160 STATUS #1, IGNORED 170 LET ERRORBITS = PEEK(746)/128 180 IF INT(ERRORBITS) <> INT(ERRORBITS+0.5) THEN PRINT "OVERRUN!" First the STATUS call is made, and the status of the STATUS goes into the variable IGNORED (which we don't check here - we assume the STATUS call itself is all right). Statement 170 takes the error bits from location 746 and divides it by twice the decimal number representing the bit being checked (as taken from Table I). In this case, we're checking for the BYTE OVERRUN erron whose number is 64, so we divide by 128. If the bit is 1, then the byte has a 64 in it, and after dividing by 128, the result has 1/2 (0.5) in ir When we add 0.5 in the next statement, we add a 1 to the result of the second INR The INTs not being equal thus means we have found a BYTE OVERRUN. If the error bit were not there, the 0.5 would add to 0 (in the 1/2 position) and the second INT would be equal to the firsr

[dmsc]

Hi!

You can emulate the STATUS call with XIO 13:

OPEN #1,13,0,"R:"
DO
  XIO 13,#1,0,0,""
  IF PEEK(749)>0
    ?"Buffer still has data..."
  ELSE
    ? "Buffer Empty!"
  ENDIF
LOOP

This should be equivalent to your code above.

Have Fun!

[rickcollette]

This is perfect. Thank you!

[dmsc]

Ok, closing then.

[rickcollette]

Should XIO 13,#1,0,0,"" be XIO #1,13,0,0,""?

[dmsc]

Yes, of course :)

Have Fun!