Jump to content
Sign in to follow this  
danwinslow

CIO Question

Recommended Posts

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...