Question: Any plans for supporting CP/M Plus on ZX Spectrum +3 with Wiznet W5100-based Spectranet network interface?

[pawosm-arm]

Recently I've prepared a FID driver (https://sourceforge.net/projects/spectranfid) for Spectrum's CP/M plus allowing to use remote disk image (N:) over the network and similarly, serial port device (SPCNET:) over the network (allowing to redirect CON: or AUX: to it). The main disadvantage of this driver is that it always connects to the same host (and the same TCP ports). It's just CP/M's block or character devices interface isn't capable to provide more control on how a FID driver should behave. Also, most of the typical network functionalities (e.g. ping, ftp) isn't available. A proper network interface would be needed. Seems like CP/Net is a step towards it. I'd give it a try some time, yet the only CP/M machines I'm having access to are Spectrums: ZX Spectrum +3 with Spectranet (build upon W5100) and ZX Spectrum Next with WiFi interface (controlled from the Next Command Line through a serial port interface), currently with no CP/M software making any use of it.

[durgadas311]

While we do already have an SNIOS for some W5500-based adapters, the W5100 has some significant differences. I did do an implementation for the W5100 early on, before we switched to using the W5500 for Heathkit computers. I can see if I can resurrect that. It never got any test time on real hardware, so there may be some things that need tweaking.

Currently, the CP/M 3 version of CP/NET (NDOS3, as available here) does not support a networked console device, although we could look into that. Note, that option would be more for a "dark" version of computer, where the human user sits remotely (and can't see the color display or touch the keyboard). We do support remote LST: devices. All of this requires that the applications use the BDOS (NDOS) to access the device, not the BIOS. Direct BIOS calls in CP/M 3 are not recommended by DRI anyway.

In CP/M 3, this CP/NET implementation uses an RSX (Resident System eXtension) to allow the NDOS to intercept BDOS calls and redirect to network devices. So it would not be using the FID technology.

Also note, CP/NET does not understand concepts like TCP/IP, Ethernet, DHCP, ping, etc. Jay has written some utilities in a separate repository for some of those features, but I believe they are strictly (or at least currently only) for the W5500.

[pawosm-arm]

Thanks for interesting reply. Seems like I wrongly assumed CP/Net implements big time networking on top of BDOS calls 66/67 (send/receive message), honestly, I never saw the real 8086 CP/Net in action (neither MP/M to which it connects).

We do support remote LST: devices. All of this requires that the applications use the BDOS (NDOS) to access the device, not the BIOS. Direct BIOS calls in CP/M 3 are not recommended by DRI anyway.

If you didn't write FID driver, how did you register a character device to which you could redirect LST:? Did you try to redirect CONOUT: there too? I'm encountering strange problem with programs using BDOS call 9 (WRITESTR) instead of 2 (C_WRITE) when console output is redirected to a character device registered by my FID driver: output does not stop at '$' and prints whatever rubbish is in the output buffer after '$'. I can't filter this out at the FID driver level as I don't see which BDOS call initiated character output, not to mention I don't really know how big the rubbish chunk is. Writing my driver I assumed it's up to BDOS to take care of it...

Anyway, since your reply answers my question, this ticket can be closed now.

[durgadas311]

Regarding how NDOS allows LST: (and CON:) to be redirected, it intercepts all BDOS calls and so can redirect LST:/CON: as desired. CP/NET has a "network configuration table" which includes 16 entries for each drive ( A: - P: ) plus an entry for CON: and one for LST:. In addition, CP/NET 1.2 (for CP/M 2.2) alters the BIOS entry vectors and intercepts direct BIOS calls for CON: and LST: - as best it can.

Regarding the FID driver and CON: with BDOS function 9, the BDOS should stop outputting characters to CON: when '$' is encountered, but I'm not sure what your FID driver is doing and how it fits into the whole BDOS/BIOS scheme on a ZX Spectrum. Is a FID driver intercepting BDOS calls? I assumed it was an integral part of the BIOS and hidden behind the BIOS JMP vectors somehow.

[pawosm-arm]

CP/NET 1.2 (for CP/M 2.2) alters the BIOS entry vectors and intercepts direct BIOS calls for CON: and LST: - as best it can.

Seems like I got used to CP/M 3 model too much, in the end, FID drivers (which are somewhat similar to Linux kernel modules as they are a convenient way of extending kernel without recompiling it) were not known before CP/M Plus and thanks to them there's no need to do all of this interception trickery when it comes to register new devices in the system.

Is a FID driver intercepting BDOS calls? I assumed it was an integral part of the BIOS and hidden behind the BIOS JMP vectors somehow.

Nah, being a part of (extended) kernel, FID driver functions are called by BIOS only. With two layers (BDOS, BIOS) between userspace program and the FID driver functions there's no way to call FID driver functions directly from userspace. And on Spectrum these things work in different memory layouts (so they never see each other): userpace runs in banks 0, 1, 2, 3 (layout 0) while FID drivers usually exist in Bank 4 or Bank 5 (which is in layout 2) with ability to force which specific bank will it be for a particular FID driver (and since I wanted to call socket library functions residing in Spectranect ROM, it had to be Bank 5, as it's the only bank that stays in the same place when Spectranet-friendly memory layout is selected).

Anyway, the fact that BDOS function 9 got fooled and continue sending characters after $ gets even more suspicious. Redirecting CON: to the SIO: character device (ZX Spectrum +3's built-in serial port) does not expose problem like that. I don't have SIO sources though, I based my driver on serial.fid sources which is a driver for some external serial port interface (SERIAL: device) that I don't even have, so I don't even know if this driver suffers from the same problem.

[pawosm-arm]

BDOS_C_WRITESTR function mystery solved: I wasn't preserving IX/IY registers in FID_C_OUTPUT/FID_C_INPUT/FID_C_O_STATUS functions! Now it works as expected! Sorry for offtop.