CP/NET serial connection

[Henk Berends]

Hello all,

I've setup a CP/NET serial connection for RomWBW CP/M 2.2 for MSX and SC720. A small beginner tutorial is here

Last year I've worked on a project with fellow MSX'er Louthrax to serve disk images through a 115K2 softserial over the MSX joystick port: MSX JIO

The CP/NET serial throughput is much less than the MSX JIO 7.5KB/s with CRC, but still very usable with the small CP/M files. Directly addressing the hardware instead of using the HBIOS driver improves it a lot on the relatively slow MSX, but I'm hoping it can be optimized a bit more. I know the internals of MSX-DOS (and CP/M) pretty well but not so much CP/NET.

Testing PIP copy 64KB test file from network drive to local drive (read) and vice versa (write), throughput in KB/s:


Some questions I have:
1. On SC720 the read from network drive is considerably slower than write. Why is that?
2. Copying files with verify from network to local drive doesn't take twice as long. How does PIP verify actually work?
3. DRI CP/NET packages seem to have considerable overhead, are there any faster CP/NET protocols for a point-to-point connection?
4. Can you disable or optimize the CRC calculation. How does it work in CP/NET?

Any other tips, tricks and experiences with CP/NET serial are also welcome.

Thanks, Henk

[Richard Deane]

Doug Miller of Durgadas.com has done a lot with CP/NET. 

An AI (Copilot) search " find me references by doug miller or durgadas to cp/net " pulls up quite a lot that may be useful.

Richard

--
You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/retro-comp/166bf780-765f-4d9b-b0ad-a2e67523bb51n%40googlegroups.com.

[Douglas Miller]

Richard's accusations are all true, sadly :-)

CP/NET over RS-232 is pretty slow. But there are lots of places for it to bog-down, including possibly the server. The protocol is a bit "chatty" and if you actually get any transmission errors it may be considerably slower to recover. Unfortunately, a lot of CP/NET requires copying to and from the message buffer, and that can add up - especially on slower CPU clocks.

As far as PIP, at least when doing a bulk copy of files, it will fill available memory with as much of the source file as possible, then write that to the destination file, and then if verify it reads back the destination file and compares to what is still in memory. So, it's pretty efficient - but does incur the cost of reading back the destination file. So, if the destination is local you're pretty good, but if it's remote then you suffer the network overhead.

I'm not sure why network file read is slower than write, unless your measurements are including some other activity we haven't (yet) accounted for. I think the total number of characters on the network is the same for both.

I've got a JAVA server at https://github.com/durgadas311/cpnet-z80/blob/master/contrib/CpnetSerialServer.jar, with documentation here: https://github.com/durgadas311/cpnet-z80/blob/master/doc/CpnetSerialServer.pdf. The source code is in a different repo, but is available. But otherwise I have put most everything I've done for CP/NET in that repo.

There is another network device I've used with CP/NET, the WizNET W5500 modules. These allow you to plug in to a LAN/WAN and we have run CP/NET over 2000 miles using that. I have also done an MP/M server based on this device. It's pretty fast, but still has the overhead of all the copying. In order to minimize the copy to/from the WizNET chip, I use Z80 block I/O instructions. I have a JAVA server for this as well. For the RC-Bus systems, this device is the MT011 by Mark T. at https://github.com/markt4311/MT011. I have no idea whether anyone has PCBs already made, or whether there have been improvements made.

The "CRC" (checksum really) used for the DRI serial protocol is not much overhead. Since send and receive must be done character-by-character anyway, it's pretty easy to just keep a running sum as you go.

Tell me more about your setup and the test methodology. One thing to keep in mind is that a 5" floppy data rate is at best (theoretical max) 3000 bytes per second, which I think is about 30000 baud. And that's not taking into account rotational latency and seek time. So if you can run CP/NET at 115200 baud (and actually keep up) you're only going to be 3-4X the speed of a floppy. Again, these are very crude comparisons that don't account for all the real-world overhead. Both floppy and CP/NET have to copy data around more than you want. And as the transmission speed increases (like near-instantaneous with the WizNET) the overhead of the copying starts to become the issue.

I have a prototype of a new SNIOS interface that can eliminate some of the copying, but that requires a new NDOS to leverage it. It also has some potential issues when running the DRI serial protocol, possibly requiring a new serial protocol to deal with that.

[Alan Cox]

The other thing that's a problem with CP/NET and indeed also older Netware is that there's no windowing so each request goes client-server-client with waits for the message and computation happening. Versus floppy it's fine but not so good versus hard disk (especially modern disk which is ludicrously faster).

Even in the old days the "good" client/server set ups often ran at 115,200 baud and uses either DMA or cunning tricks on the client end (sending a header byte so the client has time to respond then the client spins in a tight loop on the SIO chip and the like).

[Douglas Miller]

Since CP/NET clients are single-user/process, the entire client OS has nothing else to do until the BDOS function completes. CP/NET doesn't really alter that.

The implementations that I've seen using higher bauds were actually specialized interfaces to accomplish multi-drop (more like Ethernet). And often they would use (one of) the Z80-SIO synchronous protocol which relieves the CPU of much of the work (CRC, filtering messages not intended for node, ...) - which added the requirement that all nodes had a Z80-SIO.

I make no defense of the DRI serial point-to-point protocol, but it is the original reference design and possibly the only one documented. Anything that offloads work from the CPU (like the WizNET module or Z80-SIO) is a great improvement, but unfortunately each of those solutions narrows the field of platforms that can be used. Nearly all legacy platforms had an RS-232 port. 

[Alan Cox]

On Tue, 12 May 2026 at 21:51, Douglas Miller <durga...@gmail.com> wrote:

Since CP/NET clients are single-user/process, the entire client OS has nothing else to do until the BDOS function completes. CP/NET doesn't really alter that.

That's not  quite what I meant. You end up with

client [delay] server [delay] client [delay] server [delay] ....

so your round trip time actually hurts and for wifi that becomes one of the limiting factors, especially as you ping pong back and forth for each 128 byte block. Later protocols with more memory and CPU power did some level of windowing so that the delays were mostly productive.

Not really a criticism of the protocol - it's much simpler to handle a situation in which the client is not required to walk and talk at the same time.

[Henk Berends]

Thanks for the clarifications. Much appreciated!

Interesting discussion. I would like emphasize that it only takes a few steps to setup a serial CP/NET connection and even a slow network drive is so much easier to use than xmodem or swapping disk media.

For MSX the local drive speed is a factor I forgot to take into account. With my local PPIDE CF disk system and MSX-DOS, copying a 64KB file from one local drive to the other takes 3 seconds or less. In CP/M 2.2 it takes appr. 13 seconds and copying from network to local takes 27 seconds. If my calculations are correct then the network throughput is appr. 3.1 KB/s instead of the 2.4KB/s mentioned earlier.

Looking at the sources: for the universal RomWBW driver it seems like there's one or two HBIOS calls for every byte transmitted/received. I think it can be optimized by doing a direct call into the HBIOS bank, the same way as the RomWBW xmodem app. It would be even more efficent to have a single HBIOS serial network packet function, but that requires much more development work. On a Z180 system you can probably switch port 2 to console and use port 1 at 230K4 baud for the network.

/Henk

[Douglas Miller]

I agree that CP/NET is much more convenient than things like xmodem or kermit, especially when you can directly work on network files and don't have to do an addition copy (e.g. I can do a compile/assemble/link on a network drive and all parts of that are automatically accessible on the PC). But I think there's a general perception of complexity surrounding CP/NET, and apprehension of the unknown, that impedes adoption.