Poor console output performance in CP/NET

[durgadas311]

Console output, once CP/NET starts, becomes very slow. There is 33x overhead for the console output request/response sequence, and in addition the BDOS will usually check console input status which is another 32 (65x overhead). At 115200 baud this would reduce output to an effective 1772 baud.

Switching to an OOB channel for console output would fix this, however the NDOS does not allow for console output to be performed differently than console input, and the console input status checks would still be prohibitive.

Also, allowing console input to be OOB would be problematic as it might coincide with the start of a request and could throw the sequence off track.

[durgadas311]

A possible path to solution for this and issue #2 might be to expand the RCVMSG semantics to include "BC=0", meaning that the buffer used in the last SNDMSG is to be used for the RCVMSG, and the context of the receive is available in that buffer. This would allow the SNIOS to snoop the context of the RCVMSG call, and avoid waiting for a response in the case of console output - since the corresponding SNDMSG would have sent the console character directly and there will be no CP/NET response message.

The minimum changes to NDOS would be to replace the "lxi b,MSGTOP" with "lxi b,0" in the NCONCM case (common console handler), allowing customization of console handling in the SNIOS.

For this issue, there's still overhead of building up the CP/NET message, but no overhead on the data stream. This does not address the requests for console input status, though.

[durgadas311]

The solution to both issues may be to simply use OOB for all console traffic (input and output), and work out the race conditions for using CP/NET messages. The main (only?) problem seems to be the start of a CP/NET message. The client sends ENQ and expects ACK. Once the server has detected the ENQ and sent the ACK, it will divert console input to a buffer until the end of the CP/NET response. However, the client is currently too draconian about the ACK. If the initial ENQ-ACK exchange were to buffer any non-ACK character received, assuming they are console input, then once the ACK is received it should be safe to proceed. Of course, this all requires that the console traffic never contain ENQ or ACK characters. Perhaps this needs to be enforced, or these characters need to be escaped somehow. It also requires that console input/status handle the buffer as well.

Because CP/M (CP/NET) is single-user, single-process, single-thread, console input/status/output calls will never coincide with CP/NET calls. However, console input characters are asynchronous events, and those may occur during CP/NET request/response sequences - unless the server helps avoid that and the client tolerates a little overlap.

[durgadas311]

Working version, using fully OOB console, now running. The following restrictions exist:

• The client (CP/M) must never generate a ^E (ENQ) on the console output channel. It's possible this could be caught in the BIOS and converted to a CP/NET message to avoid the issue. It seems unlikely that any terminal type would use ^E as part of it's escape sequences, at least any modern ANSI terminal would not.
• The user must not generate a ^F (ACK) [at the same time the client is starting a CP/NET message]. This seems possible for certain CP/M programs such as WordStar. Not sure how to mitigate this one.