Peter wrote:That's amazing. Roughly guessing about 60KB/s actual file transfer throughput, that's already a quarter of the ethernet throughput I see with TFTP at the moment.
In practice, due to the mandatory inter-packet GAPS and other artifacts within the QLAN protocol, it measures about 32KB per sec - a display-file's worth. The bit-timing is 8x standard.
I'm confident I can squeeze a bit more out of it, but not until I can track down the culprit for the occasional lock-ups I observe at these higher bit-rates.
I have an almost complete design for a backwards-compatible enhancement to the Sinclair protocol, that would allow for dynamic/negotiated bit-timings and other capabilities between machines that can support them in a way that is invisible/transparent to any legacy machines also listening, whilst automatically reverting to the std timing and protocol as needed.
It wouldn't be as fast as the highest bit rate any given machine could support as, to be truly backwards-compatible, the packet transmission and timings must at least commence in the std fashion, only 'stepping-up' if a suitable response is received following the packet-header.
Anyways, something I'll pick up again in the future...
Peter wrote:I've been playing with the idea of replacing the physical layer for QL network to reliably get higher speeds and longer distances. I think CAN Bus transceivers would be quite ideal for that speed range, and would make the QLUB adapter even easier to solder.
Yes, I researched various bus-transceivers as a replacement for the std hardware as a side project. Even devices considered obsolete these days could support a substantial upgrade to what we have today. And all without messing about with Ethernet...
Peter wrote:The downside is, that a QL/Q68 side adapter would also be needed, and I couldn't figure out a satisfying solution yet.
Yes, any innovation in this area quickly returns to the important question - how would an typical QL user benefit from this?