danwinslow Posted February 7, 2016 Share Posted February 7, 2016 So, I'm doing a PRINT #2,"HI THERE" from basic, where IOCB #2 has been opened to my handler. I do get calls to my put byte vector, but ICCOM is 5, which is INPUT, not PRINT. Plus I seem to be getting a series of 10 or so spaces (hex 20's) before I start getting the "HI THERE" bytes. I am confused about why ICCOM is not correct and why I am getting the spaces. Is BASIC doing something weird here, or what? Quote Link to comment Share on other sites More sharing options...
phaeron Posted February 7, 2016 Share Posted February 7, 2016 BASIC doesn't call through CIO to do output -- it calls directly to the PUT BYTE handler through (ICPTL,X). You can't rely on all of the ZIOCB being set up. Quote Link to comment Share on other sites More sharing options...
Rybags Posted February 7, 2016 Share Posted February 7, 2016 You need ? #2; Otherwise it processes comma which inserts leading spaces. The PUT byte thing - it's a deviation from what CIO should have been. Probably done that way because it would have made concurrent OS and Basic development easier. Plus it could give a slight speed advantage, reduces some of the CIO overhead. Quote Link to comment Share on other sites More sharing options...
danwinslow Posted February 8, 2016 Author Share Posted February 8, 2016 You guys are awesome. Thanks, I was kind of suspecting BASIC...I'm just going to go with XIO calls. Quote Link to comment Share on other sites More sharing options...
Rybags Posted February 8, 2016 Share Posted February 8, 2016 Is this a custom device handler? You should be able to overcome the Z-page IOCB not having the proper information on Put Byte calls by Basic. If you just reference the high memory IOCB,X in that case. Also there is no check to see if the IOCB is actually opened, or check for output to an input only IOCB. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 8, 2016 Share Posted February 8, 2016 Doesn't this just work automatically if the handler's put byte routine outputs what's in the accumulator? Quote Link to comment Share on other sites More sharing options...
danwinslow Posted February 8, 2016 Author Share Posted February 8, 2016 regular IOCB is wrong, too. There does seem to be a check for OPEN and direction settings. Jon - it does, but my issue is deciding when to actually send a packet. For 'record mode' PRINT, I would want to send a packet when EOL ($9B) is encountered. That's what I wanted ICCOM for, to tell which mode I was in. It's not a big deal, I can switch to XIO if needed, and PUT doesn't work right from basic anyways. Quote Link to comment Share on other sites More sharing options...
Rybags Posted February 8, 2016 Share Posted February 8, 2016 Yep - normally you'd not care if a PUT operation is put character/s, put record, whatever. You generally either buffer the data yourself at a lower level e.g. disk, tape - or just deal with the required output operations directly e.g. screen. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 8, 2016 Share Posted February 8, 2016 Jon - it does, but my issue is deciding when to actually send a packet. For 'record mode' PRINT, I would want to send a packet when EOL ($9B) is encountered. That's what I wanted ICCOM for, to tell which mode I was in. Right - I see what you mean. Obviously I have no clue how the driver works, but maybe Put Byte could maintain its own internal output buffer with EOL triggering a packet send regardless of the context in which Put Byte is called. I'll bet it's very much more complicated than that, though. Quote Link to comment Share on other sites More sharing options...
danwinslow Posted February 8, 2016 Author Share Posted February 8, 2016 Hehe, well not too much more complicated, except that I wanted a non-EOL sensitive behavior too, as in like a binary PUT. And this is in reference to a TCP stream connection; for UDP all you would have would be the binary put, and you'd get a packet for each put you called. Quote Link to comment Share on other sites More sharing options...
danwinslow Posted February 9, 2016 Author Share Posted February 9, 2016 On an INPUT, what am I expected to do when there isn't a character available yet? Am I supposed to block reading that 1 char until I get one? I am assuming so. Quote Link to comment Share on other sites More sharing options...
phaeron Posted February 9, 2016 Share Posted February 9, 2016 CIO doesn't support non-blocking I/O and your handler should block until data is available or BREAK is pressed. Non-blocking routines are generally implemented at an upper layer by a device-specific way to monitor buffer status, such as the GET STATUS command for R: devices. Quote Link to comment Share on other sites More sharing options...
kenjennings Posted February 9, 2016 Share Posted February 9, 2016 Anything reading from a CIO device should safely deal with the fact that fewer bytes were read than requested. But, what should happen if the request is for one (or more) bytes and zero bytes are returned? Should the reader recognize length of zero? (I think so). Or should the device behave like an end of file had occurred? (probably not ideal). We are talking about the dragon network cart, right? So, as a special device never conceived of for the Atari in 1978 I think you have some lattitute for deciding appropriate behavior for the CIO user. Quote Link to comment Share on other sites More sharing options...
danwinslow Posted February 9, 2016 Author Share Posted February 9, 2016 Hehe, yeah Ken. It's most similar to an INPUT reading from a keyboard...it's not EOF, its just the person hasn't typed anything yet. I've made the routine called by BASIC on an input to a TCP channel behave exactly that way. The only way it generates a 136 EOF error is if the channel gets closed while its blocking on input. Seems to work fine. Quote Link to comment Share on other sites More sharing options...
Rybags Posted February 9, 2016 Share Posted February 9, 2016 The expected behaviour is the handler just sits idle until data becomes available. Alternatives I could think of is have applications do a Status command and have some status for no data buffered. Or return data = 00 and Status = Truncated Record. Quote Link to comment Share on other sites More sharing options...
danwinslow Posted February 9, 2016 Author Share Posted February 9, 2016 I have an XIO set up to return number of chars available. I'm using status to dump some tables for an IPCFG and an ARPCFG command. 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.