The Sinclair QL Forum

I tried sending the BLUE_scr file to the screen and the result is attached. It sent around 60 packets before it appeared to stop writing them to the screen, even though the script appeared to keep receiving acks. I’m not 100% convinced that’s not a bug in my Python though so I’ll reserve judgement. I’ve seen the same issue when simply printing received text to the screen.
As you might be able to make out, there is a fairly clear byte alignment to most of the noise; it’s not clear to me whether this is predominantly the first or last bits of the byte because I have overscan and can’t see where the byte starts exactly.

I couldn’t discern any flashing pixels.

On the question of QL <-> Spectrum networking, I was concerned that my case was an outlier because the Interface 1 I was using has been repaired (new ROM and vLA1), so I tried another Interface 1 - however I get the same result, perfect in both directions. Maybe there’s a timing aspect that turns out to be significant there.

I will continue to play, though (and if necessary dig into my pocket and get a proper board).

Hi again!

Ok, so the combination of your screen-capture (albeit, without the LHS reference-point that would allow us to be sure of the bit position of any erroneous pixels), alongside some research of my own having now disassembled the AH Network code (comparing it to later QDOS equivalents) leads me to suspect that we are seeing the AH QL periodically start to read/sample the byte-frame just a little too 'late', because:

a) We see a significant number of single Cyan pixels when we expect just Blue - this is most likely the STOP bit sent by the QLUB being misinterpreted as the last bit (Green) of the first byte of the affected video word pair: Blue + Green = Cyan (easier to understand than to explain in words.), and
b) Across ALL the original QDOS ROMs (AH through MG - even TB!), the Physical NET routines (Send/NT_SPCKT and Receive/NT-RPCKT Packet) are identical in ALL respects EXCEPT that in the AH Receive Packet routine, the Timing Constant used to align with bit-0 (that immediately follows the START bit) is a few cycles larger than in ALL the other QDOS ROMs (26 versus 19.) The subsequent inter-bit Timing Constant is consistent throughout all the ROMs I disassembled (=6.)

This _may_ also contribute to an explanation as to why you seem to have good comms with the Spectrum - the IO Contention observed in the Shadow ROM Net routine will, when it occurs, slightly stretch the byte-frame sent - sometimes by as much as 2uS to each of the first two or three bits of any affected byte - enough to upset the delicate SW loop-based timings at the receiver. And, given the Issue-5's own IO Contention when reading the ZX8302, may further exacerbate an already edge-case timing situation.

The 'stretching' at the receiver end that we see in AH could well be cancelling-out the problem

Now, given that you may not be in a position to modify the AH ROM code (though I REALLY recommend replacing with Minerva!) with the simple 2-byte adjustment to bring the Receive timing back in alignment with other versions of the OS (and the QLUB Adapter firmware), as well as the fact that this mod would probably break your QL to Spectrum comms, the simplest adjustment would be to extend the Timing Constant "BIT0_TIME_SEND" in the QLUB firmware which defaults to '20'. I'd try small increments 21, 22 etc, until you get a reliable solid Blue display. If you see no discernible improvement by the time you get to '24', then I've probably got it completely wrong and no point pursuing that particular approach.

Of course, that would require the ability to recompile/flash the currently available source with the 'legacy' tool-chain (as was discussed previously/below.) The relevant Timing Constant can be found on line 112 of v2.1f of the provided uC source code.

...Or you could wait another week or so until I release a revised firmware with more 'sophisticated' timing routines that are 'compatible' with the latest Arduino IDE/Teensy libraries (specifically the Teensy delayMicrosecond() library.)

I'd be well chuffed if that fixes it for you, but remain open to further troubleshooting if not...

Good luck!

martyn_hill wrote: [EDIT} It's when troubleshooting such mistiming issues that the rather 'loose' error checking implemented by the Sinclair Network protocol actually comes-in handy (simple byte-additive check-summing) - Were the error-checking at all robust, you would get barely any visible evidence of the corrupt packets as they would be discarded long before reaching the display... One area for an enhanced protocol that i have been investigating involves the use of modulo-255 Fletcher-16 checksums - almost as easy to compute but significantly more robust. Anyways, a story for a future Network article... [/EDIT]

The less-than-robust error detection is one of my concerns about the reliability of the original Sinclair network protocol. I'd recommend sending files only in ZIPed form so you will at least have robust CRC-32 integrity checks.

Another issue is the non-streaming nature of the protocol. Every 255-byte block has to be ACKed before the next can be sent, which degrades throughput to 50% or less of what would theoretically be possible. This even hampers performance when using Ethernet connections between emulated systems. When testing FSERVE between two QPC2 systems I got a throughput of only 200Kbps on a 1Gbit connection.

I've been doing some tests with FidoNet-style sessions over TCP/IP using QBOX, which uses SEAlink which is a streaming enhancement of XMODEM. Between the QPC2 systems a 1GB file transferred in just 4 seconds compared to 43 with FSERVE! The downside is that it's far from user-friendly at the moment and requires a lot of configuration.
FSERVE is much simpler to configure but needs adaption for better use of TCP/IP features (one could just let TCP do the low-level stuff like error correction and streaming).
(as discussed earlier it would be better to design a new FSERVE and network driver for TCP/IP use as the Q68 now supports both type of network - so lots of work to be done...)

Jan

janbredenbeek wrote:Another issue is the non-streaming nature of the protocol. Every 255-byte block has to be ACKed before the next can be sent, which degrades throughput to 50% or less of what would theoretically be possible. This even hampers performance when using Ethernet connections between emulated systems. When testing FSERVE between two QPC2 systems I got a throughput of only 200Kbps on a 1Gbit connection.

I don't think ACKing itself is the issue there. Even two Q68s achieve 200 KByte/s with TFTP, which also ACKs every block quite like QL network. More likely it comes from using TCP instead of UDP to carry the packet based QL protocol from emulator to emulator. I don't know it TCP_NODELAY is used as a socket option by QPC2 - if not that makes things worse.

Did you mean 200 KByte/s or 200 Kbit/s by the way?

Hi!

Whilst on this (off-) topic and just as a little teaser - an updated version of the ND-Q68 driver that I am still testing can push over 700 kbps (that's bits per second, not bytes) between a pair of Q68s...

Not 100% reliable as yet and possibly of limited appeal (few QL-like devices can get anywhere close except the Q68), but once I've gotten the QLUB Adapter to its next release version, I'll revisit the ND-Q68 driver development and share whatever I come up with...

Peter wrote: I don't think ACKing itself is the issue there. Even two Q68s achieve 200 KByte/s with TFTP, which also ACKs every block quite like QL network. More likely it comes from using TCP instead of UDP to carry the packet based QL protocol from emulator to emulator. I don't know it TCP_NODELAY is used as a socket option by QPC2 - if not that makes things worse.

It appears that QPC2 does honour TCP_NODELAY - I set this option on every connect which gives a significant improvement. On UQLX it doesn't appear to work as transfers are a lot slower.
(on the downside, QPC2 still doesn't signal a lost connection back to the application with EOF ).

Did you mean 200 KByte/s or 200 Kbit/s by the way?

I got about 200Kbit/s with normal SEAlink (which uses ACKs but IIRC has a window of 32 blocks i.e. 4096 bytes). With SEAlink Overdrive (which sends the whole file at once and only waits for the final ACK) I got 200KByte/s .

Jan

I've moved the circuit from the breadboard to a permanent circuit and box:

That's gorgeous, Daniele!

Put's my own make-shift effort to shame

When you get time, would you be willing to share the overall dimensions/measurements of the apertures, etc? Did you purchase a ready-made project-box, or 3D-print one yourself?

janbredenbeek wrote:(on the downside, QPC2 still doesn't signal a lost connection back to the application with EOF ).

First time I ever heard of this. What else happens then?

Marcel

Hi everyone. I'm not a netwrok guru in any way, shape or form, and I'm pretty much never ussed a QL network since time began, so I'm only just into this topic. Lockdown!

Back in December 2020, Peter asked:

Peter wrote:Is there any difference between .ino file format and and C language?"

There is and I've added a topic on the Off Topic section to explain the differences. It's at
viewtopic.php?f=9&t=3643 if anyone is interessted.

Cheers,
Norm.