CIO Question

[danwinslow]

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?

[phaeron]

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.

[Rybags]

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.

[danwinslow]

You guys are awesome. Thanks, I was kind of suspecting BASIC...I'm just going to go with XIO calls.

[Rybags]

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.

[flashjazzcat]

Doesn't this just work automatically if the handler's put byte routine outputs what's in the accumulator?

[danwinslow]

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.

[Rybags]

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.

[flashjazzcat]

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.

[danwinslow]

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.

[danwinslow]

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.

[phaeron]

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.

[kenjennings]

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.

[danwinslow]

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.

[Rybags]

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.

[danwinslow]

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.