QL Network Protocol(s)

Nagging hardware related question? Post here!
jll745562
ROM Dongle
Posts: 15
Joined: Wed Apr 10, 2019 2:15 pm
Location: Ynys Mon

QL Network Protocol(s)

Post by jll745562 »

This is a continuation of a thread first started in the 'Help for New Users' board:
viewtopic.php?f=11&t=2826

I'd just like to say a quick thanks to everyone who has contributed to this topic so far, it has been very interesting and informative.

To continue on from Martyn's comments about the SCOUT: if, as Martyn suggests there is a way of differentiating between the various 'flavours' of the protocol via the SCOUT information, I think it would be useful to document it on the wiki.
I also like Martyn's idea of encoding additional information into the SCOUT, this could lead to an almost 'plug and play' method of adding new low bandwidth hardware to the QL (parallel port anyone? midi?). This has certainly given me food for thought.

BTW, Martyn, please correct me if I'm wrong, but isn't it an PNP transistor in the NET hardware?


J.


martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: QL Network Protocol(s)

Post by martyn_hill »

Hi again Jason!

[Thanks for the correction to my earlier post - forever getting my PNPs and NPNs mixed-up! I've edited the earlier post accordingly.]

So, the different OS platforms that can 'talk' QL/ZXNET broadly encompass:
  • Vanilla QDOS (incl. Minerva for this discussion)
    QDOS + TK2 (just 'TK2', henceforth) and
    SMSQ/TK2 ('SMSQ')
    Spectrum+Interface-1 ('ZX')
As per Marcel, it seems that TK2 received some significant changes upon the arrival of SMSQ(/E); one result being a difference to the way LOAD is (now correctly) handled, as per the earlier post.

All the Hardware-based QL compatibles (bar probably the ST QVME card) have a electrically compatible Network port, including the QXL, Aurora (if I'm not mistaken) and Q68, but it's the variant of the NET driver as one of the four options above that generate the differences in implementation of the protocol - most obviously in the SCOUT phase, which is what we'll discuss here:

The following might be slightly off, but corresponds with my reading of the respective source code and then tested using a logic-analyser empirically. Always happy to be corrected :-)
  • Minerva and QDOS both take the approach of encoding only the SRC station number in the SCOUT - inverting the bottom 7-bits of SRC within a 10-bit frame of around 56 us per-bit.
    TK2 on the otherhand takes both the SRC (7-bits) and DST (3-bits) station numbers, using positive logic within a 16-bit frame, each of around 30 us each.
    SMSQ seems to vary slightly from TK2 by taking 5-bits of SRC and 6-bits of DST but within a 15-bit frame - again around 30 us each.
    ZX more closely matches QDOS, using a 9-bit frame of inverted SRC, but at around 54 us bit-time.
Representations of the first three are shown here:
SCOUT_Analysis.png
In each case, some additional 1s or 0s are added either-side the encoded values (TK2 even embeds a zero between SRC and DST), to extend the SCOUT to a suitable length, but in all cases, after a nominal period (525 us) you will not see another high to low transition until the inactive START bit is sent - indicating the beginning of the Header.

Once the listener has detected the start of the SCOUT (or, in the case of TK2 and SMSQ, atleast 50 us continuous active) following a period of inactive at least 200 us, the remainder of the SCOUT is skipped using a crude timing loop - the listener will then await active before then looking for the all important START bit, around which the actual data-bit timings are based - and reset upon the next START bit.

Coming back to Jason's question - 'How to detect whether TK2 is sending?'...

There are probably a few valid methods to proceed, but from what I can deduce, the most reliable and simple would be to time the initial active period of the SCOUT before it first goes inactive - anything OVER about 70 us is almost guaranteed to be NOT TK2/SMSQ, both of which always follow the initial active period of c60 us by 1 or 2 inactive bit-times - regardless of SRC/DST encoded values that then follow.

I say 'almost' because there is one possible edge-case of Minerva/QDOS generating a shorter initial active period in the SCOUT - that is when the SRC is configured as station number '64'.

I've seen various comments in the different source code and documentation indicating the valid range of Network Station numbers is 0-63 or 0-64 or even not checked at all. (We can ignore TK2's 'server' pseudo station numbers of 80h+SRC - bit 6 will still only be set if SRC is 64.)

Due to the listener's ignorance to the actual contents of the SCOUT, with a bit of care we could encode something else there and still maintain backwards compatibility... More in a future post, if anyone's still interested...


User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: QL Network Protocol(s)

Post by Peter »

martyn_hill wrote:All the Hardware-based QL compatibles (bar probably the ST QVME card) have a electrically compatible Network port, including the QXL, Aurora (if I'm not mistaken) and Q68 [...]
The Q40 and Q60 also lack the QL network port. At design time I saw ethernet as the way to go, plus I did not expect someone to re-adjust the timing loops.

I am tempted to supply a QLNET add-on for these QL compatibles also, but the unsatisfying Q40/Q60 video situation holds me back in general. The pseudo 1024x768 chip replacement solution works well for flatscreens, but the black bar at the bottom is simply not nice. Everything else would require so much work, that it comes close to a totally new Q60.


martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: QL Network Protocol(s)

Post by martyn_hill »

AH, yes - sorry for omitting the Qx0, Peter! The one compatible that I don't (yet) own!


jll745562
ROM Dongle
Posts: 15
Joined: Wed Apr 10, 2019 2:15 pm
Location: Ynys Mon

Re: QL Network Protocol(s)

Post by jll745562 »

Well, thanks to the help received from everyone here, I have now got my simple QL network file server working well enough for me to release the source code - it can be found at: https://github.com/dandelion-labs/QLAN
This provides an inexpensive (~15 GBP) route to adding SD storage to the QL, with some limitations. (i,e, it is a serial device, not a directory device). Still, some may find it useful.

J.


Derek_Stewart
Font of All Knowledge
Posts: 3929
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

Re: QL Network Protocol(s)

Post by Derek_Stewart »

Hi J.

I have downloaded the files from Github, I will construct the hardware next week.


Regards,

Derek
martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: QL Network Protocol(s)

Post by martyn_hill »

Hi Jason!
jll745562 wrote:Well, thanks to the help received from everyone here, I have now got my simple QL network file server working well enough for me to release the source code - it can be found at: https://github.com/dandelion-labs/QLAN
This provides an inexpensive (~15 GBP) route to adding SD storage to the QL, with some limitations. (i,e, it is a serial device, not a directory device). Still, some may find it useful.
Nice work :-)


User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: QL Network Protocol(s)

Post by Peter »

jll745562 wrote:This provides an inexpensive (~15 GBP) route to adding SD storage to the QL, with some limitations. (i,e, it is a serial device, not a directory device). Still, some may find it useful.
I find this a cool idea! The performance is much better than over the serial port. A memory-saving idea, especially nice for unexpanded QLs, or simple applications where QL-SD would be "overkill".

Isn't this worth a separate thread, with an announcement?


FrancoisLanciault
Trump Card
Posts: 167
Joined: Mon Aug 08, 2011 11:08 pm

Re: QL Network Protocol(s)

Post by FrancoisLanciault »

Hi,

With all the variations of the net protocol, it would be very nice if someone with the knowledge could create a table (in excel or other) with all version of the driver (BBQL, TK2 VXX, Minerva, SMSQ etc, including the zx spectrum) in both row and column and, at each intersection, a list of what works and what doesn't works. (For example -> lbytes:working, exec:not working, load: working)

I don't know if a single person has the complete knowledge, else it could be a group contribution.

I don't know about others but I know that I would benefit from such a summary. It can save a lot of time debugging intercommunication between QLs.

François


jll745562
ROM Dongle
Posts: 15
Joined: Wed Apr 10, 2019 2:15 pm
Location: Ynys Mon

Re: QL Network Protocol(s)

Post by jll745562 »

Derek, Please let me know how you get on - particularly with the documentation, have I given enough details for someone to successfully built it?

Martyn - Thanks! Looking forward to seeing your QLUB project in the future, it's somewhat more ambitious than my little effort!

Peter, Glad you like it, but I not sure it's worthy of some kind of 'announcement' - I'm sure people looking for such a solution will find it via this thread.

Francois - I agree, it would have be helpful to have had that information at hand when I was working on this project - however I understand that some of these issues have only just come to light (see Martyn's thread on TK2 LBYTES and Minerva), plus, as you mention, few people (if any) have all the combinations of QL network hardware to test. All I can add is that I had issues with LOAD and LBYTES on TK2 2.23 and Minerva 1.98

Jason.


Post Reply