Emulating "ZX Net" spectrum networking

We’ve been discussing this feature on the SpectrumComputing forums for a while, and here are some things mentioned so far about existing (POC?) code:

1. There may be a bug in if1.c:port_net_out, which prevents network from “sending” anything unless RS232 is “connected”:

diff --git a/peripherals/if1.c b/peripherals/if1.c
index b4ff329..2ed8083 100644
--- a/peripherals/if1.c
+++ b/peripherals/if1.c
@@ -922,8 +922,8 @@ port_ctr_out( libspectrum_byte val )
 static void
 port_net_out( libspectrum_byte val )
 {
-  if( if1_ula.fd_t == -1 )
-    return;                            /* nothing to write */
+  if( if1_ula.fd_t == -1 && if1_ula.fd_net == -1 )
+    return;                            /* nowhere to write */

   if( if1_ula.comms_data == 1 ) {      /* OK, RS232 */
     val &= 0x01;

1. Personally I do not understand what filesystem entity is supposed to be open(2)ed as fd_net. Looking at the code it most likely should be a PTY, because code reads and writes from/to the same descriptor. However, the code also lseek(2)’s using that file descriptor and that operation doesn’t make much sense for a PTY (or a pipe or a socket).

Quick summary of the Spectrum Computing discussion:
- existing code was not finished (and it tries to analyse the sequence of IN/OUT calls, which seems to be a tricky task)
- suggestion to intercept IF1 ROM routines (like it’s done for tape loader) was considered, but rejected

I would suggest implementing another approach: build a proper parser for the ZX Net protocol which will serve as an adapter between the IF1 network “socket” (port 0xF7, technically) and the virtual “wire”. Such parser will have to analyse the “pulse” timings, thus effectively reading the wire protocol. It is not an easy task, but is has at least two “pros” (feel free to add “cons”):

1. It should be possible to implement it using facilities already existing in the FUSE codebase
2. Once implemented, it may be possible to connect it with the DISCiPLE module, its ROM provides ZX Net implementation that should be compatible with IF1.

I’ve managed to create a simple “wire” simulation code. With that code the broadcast transmissions are now being sent out successfully.

There are some peculiarities of the IF1 schematics and ROM code, which I do not fully understand (hopefully, yet). If someone has a clear explanation, please share. Right now I rely on Gergely’s comments for if1.c, IF1 ROM disassembly, experimental data, and my very limited understanding of the IF1 schematics.

Anyway, here is what I observe “inside” FUSE:

• SCOUT frame: 190 T-states leader (ACTIVE) + 8 bits of 190 T-states each + 191 T-states for the SCOUT STOP PERIOD (INACTIVE)

• PACKET frame starts with 91 T-states leader (ACTIVE); each byte consists of 40 T-states of the START PERIOD (INACTIVE) + 8 bits of 40 T-states each; followed by 107 T-states (sometimes 112 T-states??) of a STOP PERIOD (ACTIVE). The last byte in PACKET has a shorter STOP PERIOD of only 88 T-states.

NOTE: There is a significant discrepancy with the Logan’s book (SCOUT LEADER is 190 T-states, not 181; PACKET STOP PERIOD is 107 T-states, not 145) but the values I observe generally match my understanding of the IF1 ROM.

However, based on that POC code I have, I think the approach with parsing ZX Net protocol may give us a working implementation with reasonable efforts.

Unfortunately, at the moment I do not fully understand all the subtleties of IF1 protocol and I could not get a (reliably) working prototype. I am publishing my changes in case if someone is able to pick it up.

Updated 2024-09-28: Cleaned up code, slightly easier to read (and smaller)

I have totally missed the fact that IF1 ULA detects the falling edge of the byte leader pulse, thus providing hardware synchronisation for every byte. With that in mind, "playback" works and broadcast transmissions are working, too. Code is nice and clean and I like it.

However, there is a significant (~5 msec) delay before the receiving machine sees inbound data and it breaks everything because at the time receiver sends ACK back to the sender the sender has already started re-transmission.

Latest code attached, if we can somehow reduce that delay it should "just work".