A dumb question for "Royal" / "RoyalTM"

[jceastham]

Hi,

Apologies; I could see no other way of getting in touch.

I'm not sure if you're aware, but there's a (quite lengthy) thread on the "Spectrum Computing" forums (with 167 replies) here :

https://spectrumcomputing.co.uk/forums/viewtopic.php?t=11935

.....but the pertinent final page is here :

https://spectrumcomputing.co.uk/forums/viewtopic.php?t=11935&start=150

In a nutshell, I've been trying to get exactly what you've achieved :

"Interface 1 - ZX-NET (with the real time UDP packet encapsulation!)."

......incorporated into Fuse for almost the last two years. It's clearly possible, because you've achieved it.......and it's been demo'd in the forum thread above.

How could your successful emulation of ZX-Net be incorporated into Fuse? I'm no coder/developer, but I do have a 30-year I.T. background - in Linux, Storage, SANs, and Networking. I'm a sys-admin, rather than a code cutter, but I would dearly love to see two instances of Fuse (either running on the same Operating system, or running on operating systems geographically apart) talking to each other via ZX-Net.

I've been in touch with Fred, who announces the Fuse releases on the SC forums, and here's what was exchanged :

Fred> It looks like fun and I'm happy to see you have something working in Spectrusty.

Personally, I'm putting all my available time into making Fuse maintainable and releasable so it doesn't fall back into being too hard to work on or check it isn't broken so it can be released. For features, I'm personally going to focus on things with wide (or personal) appeal and that are easy to validate as possible.

If someone else does the work, in order to integrate it into Fuse there needs to be a clear way for the maintainers to manage that code forever without it taking time away from other bits of maintenance. So it would need to test itself, have sufficient documentation to help it be fixed if broken, and understood if it turned out to be incomplete.

Everyone involved is very time poor as you can see with the slowed changes in new releases and new features so I can't see taking on the burden of this change myself FWIW.

---

Myself> If there's anything you can provide, to assist with achieving the above (templates for code, relevant documentation, etc.), then please steer us accordingly. I'm not the coder in this undertaking (merely an enthusiastic orchestrator :)), so apologies if that's left you scratching your head :D

---

Fred> You could look at the fuse-automation repository on the Fuse SourceForge project or the unit tests that are run with "make check", but there is nothing existing that is quite what I mean (which is why it is so hard to be confident that a change doesn't break something in Fuse). Filling this gap would be a significant effort beyond just "getting things working".

---

I'd welcome any feedback you can provide

Best Regards,

Justin Eastham

[royaltm]

Hi @jceastham ,

While I appreciate your great effort, I don't see how I can help in particular.

The Spectrum Computing forum is no longer public and I don't have an account. I tried to create one, but for some reason the registration process didn't work for me.

Fuse is undeniably the most feature-rich ZX Spectrum emulator out there. That said, its source code is, in my humble opinion, quite messy and violates a number of sound software design principles, such as separation of concerns and low coupling. Extensive use of shared global variables has blurred module boundaries and made ownership of functionality impossible to discern. I have no doubt that introducing the changes required for a ZX-NET implementation could break a few eggs, and it's hard to tell what could possibly go right unless you know the code through and through.

In other words, I'm not touching it, even with a 10-meter pole.

One of the design principles of Spectrusty was to be something completely opposite to Fuse. Although I don't have much time these days to push this project further, I stand by my vision.

ZX Interface-1 Local Area Network can send files in two different modes:

• Peer to Peer, when destination/source station number is >= 1
• Broadcast, when destination/source station number is 0

The broadcasting mode is a "fire-and-forget" kind of transmission, while P2P has a built-in mechanism for guaranteeing delivery. AFAIR, after every packet of data is sent, the driver expects the receiving party to ACK the transmission and if that doesn't happen in a certain time window, the driver re-transmits the last packet.

While in practical terms, the broadcast mode is useless, the P2P mode seemed to me like a good challenge to test the design principles of Spectrusty.

This timing constraint is where the crux of the problem resides. Most emulators execute the emulation one frame at a time. In the case of the ZX Spectrum, the emulator runs the Z80 for the duration of a complete ULA frame, after which all side effects, such as sound, video output, and transmitted data, are rendered, and passed on to the host hardware.

This works fine for asynchronous communication - such as serial ports, because data can be buffered or floppy drives/microdrives, because the emulation does not have to interface the host hardware at all.

The problem is precisely that you cannot wait until that frame boundary to process the network interaction.
Any transmission in progress will have already timed out from the IF-1 driver's perspective.

The way I see it, there are 2 potential solutions to this problem:

1. Fake the ACK response to the driver before transmitting data to the destination,
2. Stop the emulation at the Z80 I/O instruction, send data over UDP, wait for an actual ACK from the destination, continue the emulation with a real ACK or NAK.

I chose the 2nd solution, because the 1st one would nullify the driver's built-in delivery-guarantee mechanism. By faking the ACK response you would never see the driver reacting to missing packets, and thus defeating the whole purpose. I wanted to see the IF-1 LAN driver's action in its full glory. Turns out, Spectrusty already had an easy way to do it via the BusDevice interface.

The 2nd solution is not without its own problems though. By stopping the emulation and waiting for the ACK packet in real-time, you mess with the emulator's frame synchronization. In particular ZxNetUdpSyncSocket waits up to 50 ms for the UDP reply packet, which already exceeds the maximum ULA frame threshold, which is ~20ms (50 Hz).

In this case, although you can see how ZX IF-1 handles the transmission quite realistically, the emulated speed may differ significantly from the original.

Perhaps there are better solutions to be found, e.g. a mix of both approaches or doing things in parallel using threads.

I wish you luck in your pursuit, if you have any technical questions, feel free to ask here.

[jceastham]

Hi again royaltm, Apologies for the somewhat tardy response.......real life got in the way (mother-in-law going into hospital, father with alzheimer's, yada yada). I kind of get what you're saying.......that the ZX-Net protocol is synchronous, and relies on accurate, real-time timing.......That and the code base for Fuse is a dog's breakfast :-). Unfortunately, my I.T. skills don't lend themselves to software development (though it's a goal to master Z80 assembly, when I'm retired); my day job is looking after Linux servers, Storage units, and everything in between (cables, SAN switches, etc.). I've been banging the drum on the Spectrum Computing forum for the last two years........but my input has been mainly encouraging (and cajoling :-) ) people far more knowledgeable than I. The full thread is here..........and you don't need to be logged-in to read it : https://spectrumcomputing.co.uk/forums/viewtopic.php?t=11935 ......I'm not sure why you're not able to create an account; but you don't need one to read/peruse :-) Are you happy for me to share what you've emailed below? I'll remove the references to FUSE :-) It really would be great to be able to virtualise two (or more) Spectrums participating on a ZX-Net. Either by having two (or more) instances of an emulator running on a single O.S., or having instances of Spectrum emulation running on Operating Systems that are geographically apart. I'll have to do a deep dive on your Spectrusty.........at some point; I'm extremely time poor at the moment, what with working full time, running two houses (my father's and mine), and everything that life chucks our way. Let me know if I can post (an edited version) of your email below. If you get a chance to read through my topic on the SC forum, I'd appreciate your thoughts. Thanks again; if I make any progress, or there's any developments, I'll let you know. Best Regards, Justin

…

On Sun, 16 Aug 2026 at 15:48, royal ***@***.***> wrote: *royaltm* left a comment (royaltm/spectrusty#5) <#5 (comment)> Hi @jceastham <https://github.com/jceastham> , While I appreciate your great effort, I don't see how I can help in particular. The Spectrum Computing forum is no longer public and I don't have an account. I tried to create one, but for some reason the registration process didn't work for me. Fuse is undeniably the most feature-rich ZX Spectrum emulator out there. That said, its source code is, in my humble opinion, quite messy and violates a number of sound software design principles, such as separation of concerns and low coupling. Extensive use of shared global variables has blurred module boundaries and made ownership of functionality impossible to discern. I have no doubt that introducing the changes required for a ZX-NET implementation could break a few eggs, and it's hard to tell what could possibly go right unless you know the code through and through. In other words, I'm not touching it, even with a 10-meter pole. One of the design principles of Spectrusty was to be something completely opposite to Fuse. Although I don't have much time these days to push this project further, I stand by my vision. ZX Interface-1 Local Area Network can send files in two different modes: - Peer to Peer, when destination/source station number is >= 1 - Broadcast, when destination/source station number is 0 The broadcasting mode is a "fire-and-forget" kind of transmission, while P2P has a built-in mechanism for guaranteeing delivery. AFAIR, after every packet of data is sent, the driver expects the receiving party to ACK the transmission and if that doesn't happen in a certain time window, the driver re-transmits the last packet. While in practical terms, the broadcast mode is useless, the P2P mode seemed to me like a good challenge to test the design principles of Spectrusty. This timing constraint is where the crux of the problem resides. Most emulators execute the emulation one frame at a time. In the case of the ZX Spectrum, the emulator runs the Z80 for the duration of a complete ULA frame, after which all side effects, such as sound, video output, and transmitted data, are rendered, and passed on to the host hardware. This works fine for asynchronous communication - such as serial ports, because data can be buffered or floppy drives/microdrives, because the emulation does not have to interface the host hardware at all. The problem is precisely that you cannot wait until that frame boundary to process the network interaction. Any transmission in progress will have already timed out from the IF-1 driver's perspective. The way I see it, there are 2 potential solutions to this problem: 1. Fake the ACK response to the driver *before* transmitting data to the destination, 2. Stop the emulation at the Z80 I/O instruction, send data over UDP, wait for an actual ACK from the destination, continue the emulation with a real ACK or NAK. I chose the 2nd solution, because the 1st one would nullify the driver's built-in delivery-guarantee mechanism. By faking the ACK response you would never see the driver reacting to missing packets, and thus defeating the whole purpose. I wanted to see the IF-1 LAN driver's action in its full glory. Turns out, Spectrusty already had an easy way to do it via the BusDevice <https://docs.rs/spectrusty/latest/spectrusty/bus/trait.BusDevice.html> interface. The 2nd solution is not without its own problems though. By stopping the emulation and waiting for the ACK packet in real-time, you mess with the emulator's frame synchronization. In particular ZxNetUdpSyncSocket <https://docs.rs/spectrusty-peripherals/latest/spectrusty_peripherals/network/zxnet/struct.ZxNetUdpSyncSocket.html> waits up to 50 ms for the UDP reply packet, which already exceeds the maximum ULA frame threshold, which is ~20ms (50 Hz). In this case, although you can see how ZX IF-1 handles the transmission quite realistically, the emulated speed may differ significantly from the original. Perhaps there are better solutions to be found, e.g. a mix of both approaches or doing things in parallel using threads. I wish you luck in your pursuit, if you have any technical questions, feel free to ask here. — Reply to this email directly, view it on GitHub <#5?email_source=notifications&email_token=BDXOYA4545HEIYNKMTL4MNL5KHCUFA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZQHAYDAOBVG4Y2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5308008571>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BDXOYA7WXA4G4ROCVZUYIJ35KHCUFAVCNFSNUABFKJSXA33TNF2G64TZHMZDSNZTGU3TONBUHNEXG43VMU5TINZZHAYDAOBSGMZ2C5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BDXOYA25FCY2QUT4RTEXV5T5KHCUFA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZQHAYDAOBVG4Y2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/BDXOYA4XM64ZQH33SKLVH3T5KHCUFA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZQHAYDAOBVG4Y2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: <royaltm/spectrusty/issues/5/5308008571 ***@***.***>

[royaltm]

Hi @jceastham,

There was a time (when I clicked on your links) that you could not view the forum without being logged in. I can see that it has changed, and is publicly available again.

Yes, please copy and re-post the part of my response stripped of my harsh opinions on the forum.

Now that the forum is public I will look up the thread if I find some time.

[jceastham]

Hi again, I've posted an edited version of your email response (from the 16th August) on the SC forum......it can be found here : http://spectrumcomputing.co.uk/forums/viewtopic.php?p=201726#p201726 ....something occurred to me a short while ago (it happens occasionally :-) )...... *>Stop the emulation at the Z80 I/O instruction, send data over UDP, wait for an actual ACK from the destination, continue the emulation with a real ACK or NAK* ....at the risk of sounding dumb; I thought UDP (or UDP/IP) was a fire and forget protocol. Google AI might be similarly dumb : "User Datagram Protocol (UDP) is a fast, connectionless network protocol used to send data quickly without waiting for a connection or checking if every piece arrives." ......I would have thought TCP/IP would be the protocol of choice, if one wanted packet acknowledgements. I'm no doubt missing something, but I thought I'd seek enlightenment :-) All the best, Justin On Tue, 15 Sept 2026 at 20:33, royal ***@***.***> wrote: *royaltm* left a comment (royaltm/spectrusty#5)

…

<#5 (comment)> Hi @jceastham <https://github.com/jceastham>, There was a time (when I clicked on your links) that you could not view the forum without being logged in. I can see that it has changed, and is publicly available again. Yes you can copy and re-post the part of my response stripped of my harsh opinions on the forum. Now that the forum is public I will look up the thread if I find some time. — Reply to this email directly, view it on GitHub <#5?email_source=notifications&email_token=BDXOYAZTERZMXVGWPHEGB5T5PGKRHA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRYGY4TKNRQGYZ2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5686956063>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BDXOYA3O6DSD4P3JGOKOWS35PGKRHAVCNFSNUABFKJSXA33TNF2G64TZHMZDSNZTGU3TONBUHNEXG43VMU5TINZZHAYDAOBSGMZ2C5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BDXOYA4BUAS6OSPJ3UD3AK35PGKRHA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRYGY4TKNRQGYZ2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/BDXOYAY4TQ3B7ZRH32MGPJ35PGKRHA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRYGY4TKNRQGYZ2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[royaltm]

The ACK/NAK I mentioned doesn't apply to the TCP/IP protocol, but rather to the ZX-NET wire protocol, controlled by the Interface 1 ROM routines, but I understand your confusion.

Spectrum A sends a packet, then Spectrum B replies with "OK I've got this!". In the original hardware implementation I think this is some sort of state toggle on the wire. In case of emulated protocol, Spectrum B sends a UDP packet back containing a flag indicating the same thing. We know what Spectrum B wants to send, because it does a specific OUT to signal this - we can sniff it from the data bits.

As for your mentions of the IP protocol, "User Datagram Protocol (UDP) is fast...". "Fast" is a key word here.

TCP implements data stream, with a lot of noise on the wire. For each DATA packet sent there are special SYNC and ACK packets floating back and forth. You need to establish a connection first, which also takes a while. All this fuss to ensure all your data reaches destination and is not duplicated.

UDP, as you have rightfully noted, are just raw datagram packets. You can implement whatever protocol assurances you need yourself on the application level. If you received an UDP datagram you can send one (or more) back. The world of online gaming use UDP for this particular reason.

I think UDP is a right choice here. Every ZX-NET packet is represented by a UDP datagram. On the network level (and I mean IP network) we don't particularly care whether data reached a destination in the right order or if it is duplicated or not. We want ZX Interface 1 ROM software to handle all quality assurance stuff. We only emulate "a wire" between computers. A ZX-NET wire between Spectrum units is dumb as... a wire. It doesn't have any sophisticated mechanisms assuring an electron beam reaches the other end. We just want to emulate "the wire" and let ROM routines do the smart thing.

[jceastham]

Hi again,

I think UDP is a right choice here. Every ZX-NET packet is represented by

a UDP datagram. On the network level we don't particularly care whether data reached a destination in the right order or if it is duplicated or not. We want ZX Interface 1 ROM software to handle all quality assurance stuff. We only emulate "a wire" between computers. A ZX-NET wire between Spectrum units is dumb as... a wire. It doesn't have any sophisticated mechanisms assuring an electron beam reaches the other end. That all makes perfect sense. Get the packets......or rather datagrams from A to B as quickly as possible.......leave the ZX-IF1 ROM code to sort out any transmission issues. As an aside, and as you may well be aware, The FUSE people have tried (and failed) to implement ZX-Net support in the past. I recall (can't precisely remember when or where) seeing some source code that was specific to ZX-Net. I wonder if I can re-find that source code........and whether it contains a name or names.....better still; email addresses. I'd like to put to him/her/them your suggestions from your email of the 16th August (I won't drag you in........so need for the "10-metre pole" :-) ). As before, will keep you posted. All the best, Justin

…

On Tue, 15 Sept 2026 at 22:36, royal ***@***.***> wrote: *royaltm* left a comment (royaltm/spectrusty#5) <#5 (comment)> The ACK/NAK I mentioned doesn't apply to the TCP/IP protocol, but rather to the ZX-NET wire protocol, controlled by the Interface 1 ROM routines, but I understand your confusion. Spectrum A sends a packet, then Spectrum B replies with "OK I've got this!". In the original hardware implementation I think this is some sort of state toggle on the wire. In case of emulated protocol, Spectrum B sends a UDP packet back containing a flag indicating the same thing. We know what Spectrum B wants to send, because it does a specific OUT to signal this - we can sniff it from the data bits. As for your mentions of the IP protocol, "User Datagram Protocol (UDP) is *fast*...". "Fast" is a key word here. TCP implements data stream, with a lot of noise on the wire. For each DATA packet sent there are special SYNC and ACK packets floating back and forth. You need to establish a connection first, which also takes a while. All this fuss to ensure all your data reaches destination and is not duplicated. UDP, as you have rightfully noted, are just raw datagram packets. You can implement whatever protocol assurances you need yourself on the application level. If you received an UDP datagram you can send one (or more) back. The world of online gaming use UDP for this particular reason. I think UDP is a right choice here. Every ZX-NET packet is represented by a UDP datagram. On the network level we don't particularly care whether data reached a destination in the right order or if it is duplicated or not. We want ZX Interface 1 ROM software to handle all quality assurance stuff. We only emulate "a wire" between computers. A ZX-NET wire between Spectrum units is dumb as... a wire. It doesn't have any sophisticated mechanisms assuring an electron beam reaches the other end. — Reply to this email directly, view it on GitHub <#5?email_source=notifications&email_token=BDXOYA2VYRUZ6SOA34I6UA35PGY5ZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRYHA2DENRRGU42M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5688426159>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BDXOYA3WUNBXMZOJDFMQ6UT5PGY5ZAVCNFSNUABFKJSXA33TNF2G64TZHMZDSNZTGU3TONBUHNEXG43VMU5TINZZHAYDAOBSGMZ2C5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BDXOYA4BSXSB4PXO55QDDVD5PGY5ZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRYHA2DENRRGU42M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/BDXOYA4LGUBPQJEKSEYIGLL5PGY5ZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRYHA2DENRRGU42M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>